Following our previous article about how to use jOOQ with Java 8 and Nashorn, one of our users discovered a flaw in using the jOOQ API as discussed here on the user group. In essence, the flaw can be summarised like so:
Java code
package org.jooq.nashorn.test;
public class API {
public static void test(String string) {
throw new RuntimeException("Don't call this");
}
public static void test(Integer... args) {
System.out.println("OK");
}
}JavaScript code
var API = Java.type("org.jooq.nashorn.test.API");
API.test(1); // This will fail with RuntimeExceptionAfter some investigation and the kind help of Attila Szegedi, as well as Jim Laskey (both Nashorn developers from Oracle), it became clear that Nashorn disambiguates overloaded methods and varargs differently than what an old Java developer might expect. Quoting Attila:
Nashorn’s overload method resolution mimics Java Language Specification (JLS) as much as possible, but allows for JavaScript-specific conversions too. JLS says that when selecting a method to invoke for an overloaded name, variable arity methods can be considered for invocation only when there is no applicable fixed arity method.
I agree that variable arity methods can be considered only when there is no applicable fixed arity method. But the whole notion of “applicable” itself is completely changed as type promotion (or coercion / conversion) using ToString, ToNumber, ToBoolean is preferred over what intuitively appear to be “exact” matches with varargs methods!
Let this sink in!
Given that we now know how Nashorn resolves overloading, we can see that any of the following are valid workarounds:
Explicitly calling the test(Integer[]) method using an array argument:
This is the simplest approach, where you ignore the fact that varargs exist and simply create an explicit array:
var API = Java.type("org.jooq.nashorn.test.API");
API.test([1]);Explicitly calling the test(Integer[]) method by saying so:
This is certainly the safest approach, as you’re removing all ambiguity from the method call:
var API = Java.type("org.jooq.nashorn.test.API");
API["test(Integer[])"](1);Removing the overload:
public class AlternativeAPI1 {
public static void test(Integer... args) {
System.out.println("OK");
}
}Removing the varargs:
public class AlternativeAPI3 {
public static void test(String string) {
throw new RuntimeException("Don't call this");
}
public static void test(Integer args) {
System.out.println("OK");
}
}Providing an exact option:
public class AlternativeAPI4 {
public static void test(String string) {
throw new RuntimeException("Don't call this");
}
public static void test(Integer args) {
test(new Integer[] { args });
}
public static void test(Integer... args) {
System.out.println("OK");
}
}Replacing String by CharSequence (or any other “similar type”):
Now, this is interesting:
public class AlternativeAPI5 {
public static void test(CharSequence string) {
throw new RuntimeException("Don't call this");
}
public static void test(Integer args) {
System.out.println("OK");
}
}Specifically, the distinction between CharSequence and String types appears to be very random from a Java perspective in my opinion.
Agreed, implementing overloaded method resolution in a dynamically typed language is very hard, if even possible. Any solution is a compromise that will introduce flaws at some ends. Or as Attila put it:
As you can see, no matter what we do, something else would suffer; overloaded method selection is in a tight spot between Java and JS type systems and very sensitive to even small changes in the logic.
True! But not only is overload method selection very sensitive to even small changes. Using Nashorn with Java interoperability is, too! As an API designer, over the years, I have grown used to semantic versioning, and the many subtle rules to follow when keeping an API source compatible, behavior compatible – and if ever possible – to a large degree also binary compatible.
Forget about that when your clients are using Nashorn. They’re on their own. A newly introduced overload in your Java API can break your Nashorn clients quite badly. But then again, that’s JavaScript, the language that tells you at runtime that:
['10','10','10','10'].map(parseInt)
… yields
[10, NaN, 2, 3]
… and where
++[[]][+[]]+[+[]] === "10"
yields true! (sources here)
For more information about JavaScript, please visit this introductory tutorial.
| Reference: | How Nashorn Impacts API Evolution on a New Level from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog. |
