There are some (known) incompatiblities of DynamicJava with the Java Language Specification:Constant strings equality test
Constant strings are not shared. An expression like"Abc" == "Abc"
or"Abc" == "Ab" + "c"
returnsfalse
with DynamicJava andtrue
with JavaTM.Implicit use of the default ClassLoader
Since each DynamicJava interpreter instance use its own ClassLoader to load and create classes, the methods that make an implicit use of the default ClassLoader (like for exampleClass.forName
) can be the source of a different behaviour between the interpreted and the compiled programs.Named local classes
Named local classes are not yet implemented. All other sort of inner-classes are interpreted.Local classes using final variables in the redefinition of a method called in the constructor of the superclass
The following program demontrates the problem (Problem.java):public class Problem { public static void main(String[] args) { final int i = 123; new C() { int m() { return i; } }; } } abstract class C { C() { System.out.println("m() = " + m()); } abstract int m(); }This program, when compiled to bytecodes, produces the output:
m() = 0
(instead ofm() = 123
like expected) for implementation reasons.Interpreted with DynamicJava it launches an exception, again for implementation reasons.
Since the result returned by the compiled program is error-prone, it is not a bad thing that DynamicJava stops the execution of the interpreted program.