Different function signature for zero argument methods ?

[hrj]

After much tinkering I figured this is the way to call a java method from JS land:

  var method = .... // Java method
  var jvmClass = ... // Java class
  var cons = jvmClass.getConstructor(thread);
  var params = [...] // parameters for the method
  if (method.parameterTypes.length == 0) {
    cons[method.fullSignature](thread, handleReturn);
  } else {
    cons[method.fullSignature](thread, params, handleReturn);
  } 

The if condition was the biggest surprise. I would have expected that function which calls the method to accept an empty array when there are no parameters.

Although I have fixed this in my code, for the benefit for future travellers that come this way, and if you agree that it is more intuitive, I suggest having the same signature for that invoking function.

[jvilk]

I can see the confusion here. Since I work within TypeScript, my JVM->JS calls are completely typechecked, since I generate includes/JVMTypes.d.ts with entries like this:

export interface sun_management_counter_Counter extends java_lang_Object, java_io_Serializable {
  getName()Ljava/lang/String;"(thread: JVMThread, cb?: (e?: java_lang_Throwable, rv?: java_lang_String) => void): void;
}

The reason I do this is to prevent the need to allocate the arguments array in the empty case, but it probably doesn't make any difference in the long run. Perhaps I should just change the behavior to always be the third argument?

[hrj]

Since I work within TypeScript, my JVM->JS calls are completely typechecked,

Our situation is more like a REPL, where that sort of typechecking is not possible.

The reason I do this is to prevent the need to allocate the arguments array in the empty case,

The caller could pass a null when they need to optimise that.

[jvilk]

The caller could pass a null when they need to optimise that.

Yeah, so I may change it. I'll keep this open until I address it.

[jvilk]

Fixing this cleaned up some of the code in DoppioJVM, so this was a good call.