[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Java and Portable.NET
From: |
S11001001 |
Subject: |
Re: [DotGNU]Java and Portable.NET |
Date: |
Thu, 03 Jan 2002 09:42:49 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.6+) Gecko/20011216 |
Hello all again, I've been lurking for a little while longer and
Glenn Chambers wrote:
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
I think they will try to avoid source code interpretation at runtime, simply
because it makes things so much more complicated. Doing that stuff before
distribution is exactly why jit, and all compilers were made. The SEE page also
says it will take plugins for other bytecode formats, such as Parrot/Perl6.
DotGNU does not want to be victimized by vendor lockin, and the vendors of
these two are not exactly paragons of open standards.
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.
I'm about to knock everything else you say, starting with this statement, use
sodium chloride first:
complexity->runtime, except for good jit stuff
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.
The SEE is meant to modularize the bytecode execution. Extending pnet for
multiple bytecode formats forces the kind of bad design found in many
monolithic systems today, including Linux. Also, this means that one program
will have to deal with the nuances of multiple languages.
Each bytecode format, and every programming language, has different ways of
doing things that are not readily apparent, nor are necessary for most "normal"
application programming. However, these nuances take on *importance* when
creating an implementation of the language. i.e. you can't modify a CString
through a const char*, but you can through a const char[] in C++. Other minor
details like garbage collection, finalization, virtual MI, visibility also play
a role.
In other words, you might not make any errors, but that doesn't mean others
won't.
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.
Which runtime? If you mean that the Java plugin and pnet would communicate,
through what channel would they? Custom attributes would break backward
compatibility.
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.
Actually, I think they do want to do this. However, there should ideally be no
change needed to pnet to run the generated bytecode, and even MS.NET shouldn't
be able to tell the difference.
Listed on the want list are a Java compiler to IL, and a C# compiler to Java
bytecode.
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.
Java is a separate plugin, not an extension of pnet.
Items omitted from the above include JNI support, and dynamic class
loading for Java (which would obviously require the phase-two bytecode
support).
Finally, there is performance. While we could bind Java and IL exec together,
many developers on this list would scream, IMHO. Each plugin takes full
knowledge of the nuances of the bytecode formats to the optimization stage. We
are not dealing with specific file formats anymore; we are dealing with
programs, and this sort of thing can be made or broken by an edge in
performance. A second is an hour, a minute is a day. DG is designed to take
advantage of modularity w/o losing vital performance. Also, good programming
practices are expected to be followed, and it simply doesn't make sense to bind
IL and Java. The sheer complexity, no matter who implements it, is too frightening.
--
The memory management on the PowerPC can be used to frighten small children.
-- Linus Torvalds
- Re: [DotGNU]Java and Portable.NET,
S11001001 <=