[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Java and Portable.NET
|
From: |
Glenn Chambers |
|
Subject: |
Re: [DotGNU]Java and Portable.NET |
|
Date: |
Thu, 3 Jan 2002 21:53:59 -0500 |
Trying to keep this concise, but I've got a sleeping 18-day-old one one
arm, which complicates matters...
On Thursday, January 3, 2002, at 10:42 AM, S11001001 wrote:
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.
I'm afraid I don't follow any of this; what I think you are saying is
either the opposite of what previous dotGNU leadership have said, or
completely irrelevant to what I'm saying. But that could just be me.
The SEE is meant to modularize the bytecode execution.
Agreed. But I'm proposing the Java-to-CLR-bytecode design.
Extending pnet for multiple bytecode formats forces the kind of bad
design found in many monolithic systems today, including Linux.
PNet is explicitly designed to generate and to execute multiple input
bytecodes, translated at loadtime to a single common format.
Also, this means that one program will have to deal with the nuances of
multiple languages.
Agreed.
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.
Another parse failure here; I'm not getting your point. Lack of sleep
caused by the above-mentioned baby may be relevant here...
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.
In the model being ptrposed, there is only one CLR-based run time.
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.
My goal here is to maximize compatibility for reuse of existing Java
code; if we simply say that Java code for dotGNU must inherit from the
CLR System.Object, not from java.lang,Object, then we require
non-trivial modifications for any class that we want to import.
Java is a separate plugin, not an extension of pnet.
That is an alternative way to do things, but not the only choice. One
can easily imagine an Andromeda plugin that's a pure-Java
implementation, and which supports Java bytecodes rather than the CLR
bytecodes currently supported by PNet.
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.
I'm not sure if I keep missing your point, or if you simply missed mine:
This is ALL predicated on the idea of Java-to-CLR as the first step.
Java-bytecode support in PNet, as well as C#-to-Java-bytecode support in
the compiler is a documented but unimplemented feature of the current
PNet design.
But, as always, this is a case where the guy (or gal) that writes the
code decides the design. I'm going to be too busy with that baby, his
4.75-year-old brother, and their mom to do much other than lob bright
and not-so-bright ideas into the ring.
Glenn Chambers
Toledo, OH