LiveConnect Version 3 Goals
|
(listed in decreasing order of importance) |
|
|---|---|
|
|
The LC2 release of LiveConnect is not completely thread-safe. (Original applications of LiveConnect, such as OJI, did not demand strict thread-safety, so it was not a top priority for LC2.) |
|
|
Rhino (JavaScript-in-Java) and LC2 behavior diverge in subtle ways, particularly in the area of error-handling. Both Rhino and LC2 should be modified so that a single set of tests can be used for both versions of LiveConnect. |
|
|
The OJI project has made modifications to the LiveConnect APIs to adapt it for their needs and placed the result in a separate directory. The sources need to be merged into a single codebase. |
|
method resolution |
When more than one overloaded Java method is compatible with the number
and types of arguments in an invocation from JS, the choice of Java method
is made arbitrarily, by using the first one enumerated by the Java reflection
APIs. Unfortunately, the ordering of methods when enumerating is
not governed by any specification, so differences between JVM vendors can
lead to inconsistencies in LiveConnect behavior.
Instead, we will define a JVM-independent set of rules to choose among overloaded Java methods. |
|
method resolution |
The weak correspondence between the JS language typing system and Java's
results in ambiguity and/or shadowing when resolving among overloaded Java
methods, e.g. JS's number type can map to any of Java's floating-point
or integral types: byte, char, short, int, long, float, double.
We need a way to bypass the method overload resolution process and explicitly specify the method to be invoked. For example: myPrintMethod = java.io.PrintStream["print(double)"];
|
|
|
The Java language allows static methods to be invoked using either the class name or a reference to an instance of the class, but current versions of LiveConnect allow only the former. |
|
JS string methods |
In current versions of LiveConnect, it is necessary to convert Java
Strings to JS strings before using them as the receivers of JS string methods,
typically by appending an empty string to the Java string, e.g.
s = s + ""; // s is now a JS string s.match("oo") The goal is to eliminate the requirement for explicit conversion to
a JS string by treating java.lang.String objects as a special case
that "inherit" all the methods of JS strings, i.e. so that the second statement
in the example above becomes superfluous.
|
|
JS array methods |
The JS Array functions are intentionally generic, so it should be possible to apply JS array utility methods such as reverse() and join() on JavaArray objects. |
|
JS language features |
Add support for instanceof and in additions to ECMA language. |
| Java exceptions converted to JS exceptions. Uncaught exceptions propagated to Java callers, i.e. when Java calls JS calls Java. |