[DotGNU]Java and Portable.NET

[Glenn Chambers]

I've been thinking off and on about how a Java-to-IL compiler could be 
made to work, and have a bunch of rather ill-defined ideas.  I've been 
waiting until cscc et al are able to compile pnetlib before I made much 
noise, but given that someone's actively pursuing the project, I'd like 
to get them out into the open.

The long-term goal of DotGNU, as I understand it, is to allow all of the 
following formats to be accepted by the system for 'secure' execution:

1.  C# source code
2.  .NET .dll and .exe files
3.  Java source code
4.  Java .class files

The optimum solution allows full cross-language capability, so that a 
Java file can reference a C# class, including deriving a new Java class 
based on a C# class.

My strategy for this is as follows (much hand-waving, since I haven't 
actually done a full design yet.)

1.  Extend the Portable.NET engine to include new internal attributes to 
support multi-lingual nomenclature for a class type.  In particular, the 
CLR class System.Object should be the same as the Java class 
java.lang.Object.  When a bit of Java code iterates over calls to the 
'get parent class' reflection function, it should top out with 
java.lang.Object, even if the object in question is originally a C# 
class.  Likewise in the other direction, if C# code queries the CLR 
equivalent.

2.  Modify the 'System.Object', 'System.String', and other classes to be 
named later, so that all 'runtime' objects can be accessed  'natively' 
from both languages.  For example, this requires a 'getClass' method to 
be added to the System.Object class, and that the 'GetHashcode' method 
also be callable from Java code as 'getHashcode'.  I haven't attempted 
to determine if there are any class methods that would require 'shims' 
in order to make this work.  (e.g., where the 'same' method in both 
systems takes incompatible argument types, or returns an incompatible 
result type.)  This would be best done via custom attributes recognized 
by the runtime.

3.  Implement a Java compiler plugin for CSCC, by ripping the parser and 
lexer out of GCJ, and using the same code generation libraries as the 
existing C# plugin.  (jv-scan might be a better organ donor, since it 
has much
less pre-existing code to rip out.)  This will compile to IL assembler, 
just as CSCC-CS does.

4.  Grab as much of the Classpath/libgcj source code as possible (modulo 
the 'dual-interface' classes created above) and compile it into a set of 
'java.*.dll' objects.

Each of the above steps will require extending the existing code; the 
extensions should probably be optional at ./configure time (e.g., a 
--enable-java option)

Phase two would extend the runtime system to be able to load and search 
.class and .jar files to do library resolution for Java, including 
adding CVM coders that parse Java bytecodes.

Items omitted from the above include JNI support, and dynamic class 
loading for Java (which would obviously require the phase-two bytecode 
support).

I probably have the technical expertise to actually do all of the parts 
I described, and probably to figure out what I've missed., but I doubt 
if I would have the time to actually do it, which is another reason I've 
kept quiet.

Glenn Chambers
Toledo, OH