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:
Number of classes in files
References to other classes
When refering classes in other files a difference exist: 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: 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: 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:
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

Debuggers

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