Re: [DotGNU]Java and Portable.NET

[S11001001]

Glenn Chambers wrote:

> 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.


Quotes from www.dotgnu.org (or www.gnu.org/projects/dotgnu/, which is where I 
first found it ;]:

Other bytecode formats, such as Python bytecode, or the bytecode of Perl6, 
could be supported by similar plugins.

From DotGNU projects list in the FAQ:
  2. CLR plugin for SEE
     - must run on all major desktop systems

  3. Java VM plugin for SEE
     - must run on all major desktop systems

While some of the language on /see.html is ambiguous (one could get confused 
about the separation of Java and IL plugins), it is clarified in the FAQ, and 
/see.html has obviously not been worked on very much... :-( OT: In fact, I'd 
like to rewrite that page, if webmaster would have me...


> > The SEE is meant to modularize the bytecode execution.
>
>
> Agreed.  But I'm proposing the Java-to-CLR-bytecode design.


I think compiling Java bytecode to IL would slow execution time, and 
overcomplicate the interpretor/JIT; however, I am in favor of a Java SOURCE to 
IL compiler.


> > 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.


Now I'll say, maybe we should ask Rhys WHY? I thought that the purpose of his 
"bytecode JIT" was to simplify things for execution, not support multiple 
bytecodes such as Java && IL. Might be wrong though...thus the WHY?


> > Also, this means that one program will have to deal with the nuances 
> > of multiple languages.
>
>
> Agreed.


Amazing, isn't it?


> > Each bytecode format, and every programming language, has different 
> > <snip>

> > 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...


Sorry, just elaborating on the earlier mention of nuances...


> <snip>
> In the model being ptrposed, there is only one CLR-based run time.


And why should it deal with Java bytecode, practically?


> > > 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.
>
> > <snip>
>
> 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.


We may both be. But the bytecode translation (Java<->IL) just seems like a 
waste of time.


> <snip>



--
Anyone who thinks UNIX is intuitive should be forced to write 5000 lines of
code using nothing but vi or emacs.  AAAAACK!
        -- Discussion on the intuitiveness of commands, especially Emacs