Re: [DotGNU]Java and Portable.NET

[S11001001]

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