[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]