Re: [DotGNU]Re: Java and Portable.NET

[Glenn Chambers]

On Saturday, January 12, 2002, at 04:01 PM, Marcin Krotkiewski wrote:

> First of all, a Java bytecode - Il bytecode compiler is not enough.
> Suppose someone writes a program in Java and compiles it to IL. This
> program most probably calls java system methods, not mentioning language
> specific issues, like Object, String, exceptions etc. IL code produced 
> that way
> will not be portable (i.e. it will only run on Portable.NET). As Glenn
> said, we would like such program to run on any .NET implementation
> (including MS one), so from practical point of view such bytecode is 
> useless.
> And the same thing the other way round - C# compiled to JL, but using
> NET system calls is, too, useless. Nobody will actually use these 
> features
> of Portable.NET, as it will only cause portability problems.

As I see it, there are two possibilities, possibly controlled by a 
compiler option.  Option
A is to compile against a 'pure' CLI implementation.  This allows you to 
write completely
portable code in Java, at the cost of 100% compatibility with the 
original language.
Option two is to compile against the dotGNU-enhanced library, which 
includes
compatibility methods on the System.Object class to allow 'standard' 
Java code to
run successfully.  The latter mode is the one I was trying to discuss.  
The advantage of
the second option is 'vendor-lockin' against a Free (Libre) 
implementation, and the
ability to use the large body of Java code without modification.  The 
advantage of the
former mode is that the compiled object can run on any CLR: dotNET, 
Mono, or dotGNU.

As long as  I'm specifying Someone Else's Work, I'd vote for both.

(Example:  In both options, you can reference 'String' and be actually 
pointing
at the CLI System.String.  In the former case, all method references are 
to the
CLI names and the classname returned by reflection is 'System.String'.  
In the
latter case, it *looks* like you're referring to a normal 
java.lang.String object,
even though its an 'enhanced' System.String object under the hood.

> That's why I think we should implement a translation module,
> which would translate between Java<->.Net system calls and language 
> properties
> when compiling to the other platform.
> This may not be possible in some cases (in case of non-existant
> classes/methods/system types etc. on either of the platforms), or maybe 
> it will
> not be possible to do it through simple textual substitutions.
> In both cases we could either provide OpenSource, Free substitutes for 
> missing
> classes/methods and add them to the program at compile time, or we could
> add some extra code, which would solve the compatibility issues
> (also at compile time).
>
> This approach would allow us to compile programs transparently between 
> both
> architectures. The ability to include C# classes in Java programs and 
> vice versa
> could still be included, but in that case using it would be the 
> programmer's
> own choice.

I don't think you can solve the dual-interface problem with a shim 
layer, which is
what I think you're proposing, unless you're planning on inserting 
translation
thunks between all cross-language calls, which gets really ugly if you 
try to
write a C# class that inherits from a Java class that inherits from a C# 
class.

If you don't allow cross-language inheritance, you've got a smaller 
problem, but
the resulting system is a lot less flexible.

> Am I right, or maybe I am missing something important about .NET? I 
> wouldn't
> suspect MS supports JL execution in their .NET implementation.

I would be astounded if the MS system supports Java bytecode.  I'd also 
be
surprised if the 'J#' system simulated the standard Java class library.

Glenn Chambers
Toledo, OH