Comparison of JVM and .NET platforms

Below follows a list of notable differences in the JVM and .NET platforms, which has had effect on our code generation principles.

References to fields

When refering a field F in an object OBJ of class CLS, which has superclass SUP, and where F is declared in SUP a difference exist:

In .NET you must refer the field as SUP::F
In JVM you must refer the field as CLS/F

Number of classes in files

In JVM each public class must be in a separate file, with the same name as the class
In .NET any number of classes (and other stuff) can be packed into an assembly

References to other classes

When refering classes in other files a difference exist:

In .NET you must in general refer the other class using a fully qualified name:
[resolution]namespaces.class
where resolution (which we internally call location) is the file location of the dll/netmodule/exe containing the class.
In JVM you need not specify any resolution/location, as long as the class loader can find the class in the CLASSPATH. This, of course, is possible because the class wil be in a file of the same name.

On .NET this has caused us some troubles because our separate compilation scheme means that when generating code for a class containing unbound SLOTS in general we do not know in what files these SLOTs are bound, and thus we cannot know how to refer these classes.
The solution we have chosen is to generate every SLOT binding (fragment form) in a separate file with the same name as the SLOT (much in the JVM style).
Instead of using fully qualified names for classes, one can chose to use partial assembly names, and then use the methods of the Assembly class in the system.reflection namespace. we have tried to do this but did not succeed.

Allocating new objects

When allocating new objects a difference exist:

In JVM you first call new and then call the constructor <init> of the newly generated object.
In .NET you call newobj with the constructor of the class as argument. Then newobj calls the constructor.

This implies one difference in code generation: On .NET you must push all arguments to the constructor before calling newobj, whereas on JVM, you push the constructor arguments after the new call (just before the call of <init>).

Local variables

For local variables in functions a difference exist:

In .NET all local variables must be declared with type
In JVM you only declare how many local variables you need

This means that where you can sometimes reuse local variables for different values in JVM, you cannot do this in .NET unless the different values are of the same type.

Different stack manipulation bytecodes

Despite being a stack based architecture, .NET has chosen to leave out some of the stack manipulating bytecodes, that JVM has:

.NET has no swap instruction
This affects the evaluation order the compiler can use, but can in general be solved.
.NET has no dup_x1 or dup_x2 instructions
This has proven to be a complicated problem for us. E.g. the BETA evaluation
```
x -> y -> z
```
demonstrates this: The java code for this is
```
<push object of z field>
<push object of y field>
<evaluate x> ; pushes result on stack
dup_x1
putfield y
putfield z
```
However in .NET we have to use a local variable to store the duplicate in. And since local variables are typed (as noted above) we need a separate local variable for each situation, where we would have used dup_x1:
```
<push object of z field>
<push object of y field>
<evaluate x> ; pushes result on stack
dup
.locals init ([n] <type of x>) // n is the next free local
variable slot
stloc n
stfld y
ldloc n
stfld z
```

Different float addressing

In various situations you must reserve two slots when addressing floating point variables in Java bytecode. E.g. when an argument for a methods is a float, the next argument is addressed two numbers higher.
On .NET this is not an issue - the variables are numbered sequently no matter their types.

Java lack of keyword escaping

When generating bytecode for BETA, the do-parts of patterns where originally turned into a method called do(). If java code is to call this method directly, currently the only means for doing this is by using reflection, since the word do is a reserved word in Java.
In contrast, in C# one can call such a method by "escaping" the keyword (using @do()). But due to the problem in Java, we now instead call this method Do (capital D).

No Java graphical debugger that supports non-java source files?

Unlike the nice experience with Microsoft Visual Studio .NET source level debugging (see Source Level Debugging) we have so far had no success in doing source level debugging in any graphical Java debugger.

The following IDE's and debuggers have been tried. None of them seem to respect a Sourcefile attribute which points to non java source files. Some even did not allow opening a class file directly, and the ones that did all generated a Java source file stub from the BETA generated class file.

IDE's

NetBeans [http://www.netbeans.org]
Eclipse [http://www.eclipse.org]
JBuilder 7 [http://www.borland.com/jbuilder]
Oracle9i JDeveloper [http://www.oracle.com/ip/develop/ids/]

Debuggers

SUN javadt [http://java.sun.com/products/jpda/]
jswat [http://www.bluemarsh.com/java/jswat/]
jdebugtool [http://www.debugtools.com]
jdpkg [http://www.cs.huji.ac.il/support/docs/java/jikes/jd.html]

All seem to depend on JDI (Java Debugger Interface), which is assumed not to support non-java sourcefiles.
On the other hand jdb support non java source files(?)

Command line wrappers

jdbtool [http://www.oops.demon.co.uk/jdbtool]
ddd [http://www.gnu.org/software/ddd/]