plasma-umass / doppio

Breaks the browser language barrier (includes a plugin-free JVM).

Home Page:http://plasma-umass.github.io/doppio-demo

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Class.setSigners / getSigners are Unimplemented

dimondl opened this issue · comments

Hi!

I have a problems with classes usage from org.eclipse.jdt jars.
I tested in two environments - latest doppio (build from github) under Ubuntu (LTS 14.04, node v4.5.0) and at live demo page (http://plasma-umass.github.io/doppio-demo/) in Google Chrome (Version 53.0.2785.116 m (64-bit)) .

log.txt

Eclipse jdt builded from latest sources with necessary libs from maven can be found here: https://github.com/dimondl/doppio_test

*I renamed all original jars to simplified usage from command line.
@jvilk @hrj

Regards,
Dmitry

commented

Thanks for the detailed report @dimondl . I am able to reproduce this on my system. Will dig deeper.

commented

I was able to trace the root cause for this: Class.setSigners(Object[]) is not yet implemented by doppio.

@dimondl As a temporary workaround you could try this patch:

diff --git a/src/natives/java_lang.ts b/src/natives/java_lang.ts
index ab8a58b..7f40c66 100644
--- a/src/natives/java_lang.ts
+++ b/src/natives/java_lang.ts
@@ -142,7 +142,7 @@ class java_lang_Class {
   }

   public static 'setSigners([Ljava/lang/Object;)V'(thread: JVMThread, javaThis: JVMTypes.java_lang_Class, arg0: JVMTypes.JVMArray<JVMTypes.java_lang_Object>): void {
-    thread.throwNewException('Ljava/lang/UnsatisfiedLinkError;', 'Native method not implemented.');
+    // thread.throwNewException('Ljava/lang/UnsatisfiedLinkError;', 'Native method not implemented.');
   }

   public static 'getEnclosingMethod0()[Ljava/lang/Object;'(thread: JVMThread, javaThis: JVMTypes.java_lang_Class): JVMTypes.JVMArray<JVMTypes.java_lang_Object> {

The test case works with the above patch; however, your actual app may not.

@jvilk I could try to implement that native method. Do you have some hints to share?

@hrj Yes, simple usage now works (after this changes). Thank you.

@hrj Thanks for volunteering and finding the issue!

From a brief look at HotSpot's sources, it looks like you need to add an injected field to java.lang.Class called signers, then implement setSigners and getSigners to set/get this field (although note some of the sanity checks in those linked files).

If you decide to undertake this task, could you also add a simple test that checks that it works, and maybe tests some of those sanity checks (e.g., trying to set signers on an array class)?

Thanks again.

Note that adding a new injected field invalidatesincludes/JVMTypes.d.ts, so you'll need to do a clean build that regens that file!

commented

@jvilk Thanks for the hints. I am not sure what an injected field is. Lazily created field to save memory?

From the reference it looks like a simple getter + setter pair with a few sanity checks. I think it is best you implement it since you might be able to do this quicker than me. If you are tied, let me know.

@hrj It's a field on a JVM object that is not contained in the class definition file -- an internal field visible only to the JVM. We specify them here -- including their initial value and TypeScript type.

I might be able to squeak this change in later on tonight. If you think you want to take a stab at it, please reply here to let me know and have at it!

commented

@jvilk Ah, I see; thanks. I will take a stab at it tomorrow (it's past midnight here); unless someone beats me to it.

commented

@jvilk Do you plan to make an npm release with this fix soon?

@hrj Sure, I can look into this tomorrow and potentially address the doppioh error issue.

@hrj Done!