You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.



LiveConnect Version 3 Goals

Task/Feature
(listed in decreasing
order of importance)
Details
Thread-safety
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 compatibility
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.
Convergence with OJI 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.
Predictable overloaded
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.

Explicit overloaded
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)"];
myPrintMethod(13);

Invocation of Java static methods using a Java instance
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.
java.lang.String objects "inherit"
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 = new java.lang.String("foo")
    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.

JavaArray objects "inherit"
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.
Support for new
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.