[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DotGNU]Java and Portable.NET
From: |
Glenn Chambers |
Subject: |
[DotGNU]Java and Portable.NET |
Date: |
Fri, 28 Dec 2001 21:29:58 -0500 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [DotGNU]Java and Portable.NET,
Glenn Chambers <=