Task/Feature
(listed in decreasing
order of importance)
|
Details
|
Duration
|
|
Percent complete
|
|
Thread-safety
|
The LC2 release of LiveConnect is not completely thread-safe.
(Original applications, such as OJI, did not demand strict thread-safety,
so it was not a top priority for LC2.) In the future,
thread-safety will be a requirement. Right now there are a bunch of placeholder
THREADSAFETY
comments in the LC2 code. |
7 days
50%
|
|
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. |
4 days ???
0%
|
|
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. |
3 days
80 %
|
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. |
10 days
0 %
|
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. Norris suggested this syntax:
myPrintMethod = java.io.PrintStream["print(double)"];
myPrintMethod(13);
|
2 days
0 %
|
|
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. |
1 day
0%
|
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.replace("o", "bar")
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.
|
1 day
0%
|
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. |
1 day
0%
|
Support for new
JS language features
|
Add support for instanceof and in additions to ECMA
language. |
1 day
50 %
|
| Java exceptions converted to JS exceptions. Uncaught exceptions
propagated to Java callers, i.e. when Java calls JS calls Java. Mike
Shaver is responsible for this work. |
2 days
50%
|
| Performance tuning |
Some JS consumers have requested that we spend some time characterizing
the multithreaded performance of LC and possibly spend time tuning it.
There is also some concern about reducing the impact of the barrier synchronization
imposed by JavaScript GC on multithreaded apps. |
??? (Potentially,
a lot of time)
0 %
|
