Native methods: Support "import" property to ensure needed classes are initialized

[jvilk]

Our need to make method calls asynchronous makes writing native methods quite messy, as we have to distribute initialize checks through them. For "hot" native methods, we often have two paths through the method: a "slow" path that performs initialization, and a "fast" path that can perform the method synchronously. The "slow" path returns undefined, and the "fast" path returns the JVM method's return value.

In addition, native methods are populated with calls to the classloader to retrieve ClassData objects.

A simple change to our native method structure will let native methods for a particular class "import" classes into a structure on the native method object passed to the VM, eliminating the slow path and the need to call the classloader for statically determinable classes.

Further details will be posted when I've thought further on the syntax.

[ghost]

Can I define natives in VM callback function? such as,

new doppio.JVM({
  bootstrapClasspath: ['/sys/vendor/java_home/classes'],
  classpath: ['/sys'],
  javaHomePath: '/sys/vendor/java_home',
  extractionPath: '/tmp',
  nativeClasspath: ['/sys/natives'],
  assertionsEnabled: false
}, function(err, jvmObject) {
    registerNatives({
      'com/example/Test': {
        'consoleLog(Ljava/lang/String;)V': function(thread, arg0) {
           console.log(arg0.toString());
        }
      }
    });
});

[jvilk]

@bertung yup, you sure can. There's no strict requirement to use separate JS files on the native classpath like I do for the built-in natives; those are more of a convenience, as DoppioJVM re-evals those files with each run to prevent state from being shared across JVM invocations.

[ghost]

Outstanding thanks