svlug-moen_on_java_on_linux

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



From: Rick Moen <rick@linuxmafia.com>

begin  Karsten M. Self quotation:

> Note that Netscape's Java implementation has often been described as
> borked.

A more salient question is:  Why the _hell_ would anyone consider
running Netscape Communicator 6.x, when Mozilla 0.9.x, Konqueror 2.1.x,
and Galeon are here and are open source?


But enough clues for the evidentially challenged.  Let's get back to Java:

Java on Linux is starting to get at least a _tiny_ bit more interesting 
than it used to be.  I believe you were the one who pointed out
Mozilla's OJI interface.  What you may know is that there's now a
somewhat respectable open-source JRE that works in that interface --
Japhar.  See: http://www.japhar.org/oji.html

Sun's JRE/JVM/JDK stuff has always been proprietary -- and therefore so
has Blackdown's (http://www.blackdown.org/java-linux.html), being a port
of Sun's code to Linux.  And Sun's Java has been, I take it, a bit of a
moving target for open-source coders, such that most of their offerings
lag Sun's in version support.

I'm going to attempt a summary of the Java model, to the best of my
understanding.  (The nice thing about doing so is that experts will
probably step in to correct any parts I flub.  Paging Nathan Myers.
White courtesy telephone, please.)


A Java programmer feeds his human-readable Java source through a
compiler typified by Sun's proprietary "javac", or its open-source
competitors Jikes
(http://www10.software.ibm.com/developerworks/opensource/jikes/?aw=50)
the now-unmaintained "guavac"
(ftp://ftp.yggdrasil.com/pub/dist/devel/compilers/guavac/), and gcj, the
GNU Compiler for Java (http://gcc.gnu.org/java/).  Any such compiler
also needs an installed set of Java class libraries, discussed briefly 
below.

The output of that compiler is (binary) object "p-code" for the virtual
machine Sun intended all Java code to run on -- "Java bytecode".  In
Sun's model, the bytecode is fed to that virtual machine and executed in
interpreted fashion.  (That's the form in which proprietary Java code
tends to get distributed, of course -- no user access to source code
required.)

(I'm not going to even try to disambiguate the terms "Java Runtime
Environment" from "Java Virtual Machine".  Maybe some Java-head will
explicate.  The references I've seen seem to define a JRE as a runtime
bytecode interpreter and assocated libs, and a JVM has that plus a class
browser for developers' usage, but this all is murky to me -- and I may
well have misread.)

Anyhow, Sun produces the proprietary Java interpreter shipped packaged
with Netscape Navigator/Communicator.  The one that either harfs
Netscape all the time, or that Netscape harfs from above, take your
pick.  Open-source alternatives:  


Kaffe, by Transvirtual Technologies, Inc.:  
GPLed JVM bytecode interpreter implementing "PersonalJava" (JDK 1.3) specs.  
http://www.kaffe.org/

Japhar
http://www.japhar.org/
JVM.  Interpreter.

SableVM
http://www.sablevm.org/
Interpreter only.  You need class libraries (SablePath).

KissMe
http://kissme.sourceforge.net/
Interpreter only.  You need class libraries (GNU Classpath).


Sun would prefer that all Java code end up compiled down to nothing
lower than the Java virtual machine (compiled to bytecode), on grounds
that compiling it further (to native machine code) "destroys
portability, which is one of the main benefits of Java" (Java
Programmers' FAQ, section 4, question 4).  But quite a number of
compilers have sprung up from third parties that compile
bytecode-to-native-binary.  These are dubbed "Just In Time" compilers,
and should not be confused with Java-source-to-bytecode compilers such
as Sun javac, Jikes, and guavac.

Open-source JITs I've found are as follows:


Kaffe, by Transvirtual Technologies, Inc.
JIT compiler (bytecode-to-native).
http://www.kaffe.org/

CACAO
http://www.complang.tuwien.ac.at/java/cacao/  
JIT compiler (bytecode-to-native).
DEC Alpha only.
Binary-only for now, to be GPLed in the future.

TYA
http://sax.sax.de/~adlibit/
ftp://gonzalez.cyberus.ca/pub/Linux/java/
JIT compiler (bytecode-to-native).
Orphaned.

shuJIT
http://www.shudo.net/jit/
JIT compiler (bytecode-to-native).

JVM-JIT compiler called ElectricalFire.
http://www.mozilla.org/projects/ef/
MPLed JIT compiler (bytecode-to-native).
You need class libraries (GNU Classpath or Sun JDK 1.2).

LaTTe
http://latte.snu.ac.kr/
BSD-licensed.  Solaris-SPARC only, for now.
JIT compiler (bytecode-to-native).

KissMe
http://kissme.sourceforge.net/
JIT compiler (bytecode-to-native) under development.

Intel Open Runtime Platform
http://www.intel.com/research/mrl/orp/
BSD-licensed JIT compiler (bytecode-to-native). You need class libraries
(GNU classpath).

gcj  GNU Compiler for Java
http://gcc.gnu.org/java/
GPLed.  Compiles in any of these three modes:
Java source code directly to native machine code (needs GNU Classpath),
Java source code to Java bytecode (class files), 
and Java bytecode to native machine code (JIT).



Sun of course provides class libraries with its various Java pieces,
but there are open-source projects to take their place, too:

GNU Classpath
http://www.gnu.org/software/classpath/

SablePath
http://sourceforge.net/project/showfiles.php?group_id=5523

Kore Class Libraries
http://www.cs.utah.edu/flux/java/kore/
Now made obsolete by Kaffe's core classes.



Now, *I* don't really know diddly-squat about Java, personally.  I just
hunt down information on the Net, and squirrel it away for later
investigation, mostly.  But there are people who _are_ genuine experts,
and they've been busy writing:

jGuru Linux FAQ by Nathan Myers and others
http://www.jguru.com/faq/home.jsp?topic=Linux&page=2

Java FAQ
http://www.faqs.org/faqs/computer-lang/java/programmers/faq/

I hope the above is of use to some folks.

===

Date: Tue, 07 Aug 2001 04:17:29 -0700
From: Jeffrey Siegal <jbs@quiotix.com>
To: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] Netscape 6.01

Rick Moen wrote:
> A Java programmer feeds his human-readable Java source through a
> compiler typified by Sun's proprietary "javac", or its open-source
> competitors Jikes
> (http://www10.software.ibm.com/developerworks/opensource/jikes/?aw=50)
> the now-unmaintained "guavac"
> (ftp://ftp.yggdrasil.com/pub/dist/devel/compilers/guavac/), and gcj, the
> GNU Compiler for Java (http://gcc.gnu.org/java/).  

All good so far.

> Any such compiler
> also needs an installed set of Java class libraries, discussed briefly
> below.

Only if the program uses such libraries, and/or if you want to execute
the compiled program.

> The output of that compiler is (binary) object "p-code" for the virtual
> machine Sun intended all Java code to run on -- "Java bytecode".  In
> Sun's model, the bytecode is fed to that virtual machine and executed in
> interpreted fashion.  (That's the form in which proprietary Java code
> tends to get distributed, of course -- no user access to source code
> required.)

Correct, but in practice the byte code is very close to source code. 
There are decompilers which can produce something very close to original
source code from byte code.  Byte code obfuscators turn compiler-output
bytecode into something that is harder to decompile.

> (I'm not going to even try to disambiguate the terms "Java Runtime
> Environment" from "Java Virtual Machine".  Maybe some Java-head will
> explicate.  The references I've seen seem to define a JRE as a runtime
> bytecode interpreter and assocated libs, and a JVM has that plus a class
> browser for developers' usage, but this all is murky to me -- and I may
> well have misread.)

The JVM is what actually executes Java byte code.  A JRE is JVM plus
associated libraries.

> Sun would prefer that all Java code end up compiled down to nothing
> lower than the Java virtual machine (compiled to bytecode), on grounds
> that compiling it further (to native machine code) "destroys
> portability, which is one of the main benefits of Java" (Java
> Programmers' FAQ, section 4, question 4).  But quite a number of
> compilers have sprung up from third parties that compile
> bytecode-to-native-binary.  These are dubbed "Just In Time" compilers,
> and should not be confused with Java-source-to-bytecode compilers such
> as Sun javac, Jikes, and guavac.

Not exactly.  

There are just-in-time compilers and ahead-of-time compilers.  Sun has
no objection to JIT compilers, in fact they produce their own (called
Hotspot). JIT compilers *transparently* convert byte code to native code
and then execute it, rather than directly interpreting the byte code. 
This makes Java byte code run faster, sometimes approaching the speed of
native code.

Ahead-of-time compilers convert either Java source code or Java byte
code to native code, like a traditional compiler for C or FORTRAN, etc. 
Sun is not a big fan of this, because it reduces Java from being a
hardware-independent platform to being just another programming
language.  To Sun's credit, this position has more merit now that the
performance of JVMs have improved by using better JIT compilers.

===

Date: Wed, 8 Aug 2001 02:43:12 -0700
From: Rick Moen <rick@linuxmafia.com>

Jeffrey Siegal <jbs@quiotix.com> wrote:

> Only if the program uses such libraries, and/or if you want to execute
> the compiled program.

Sort of like "the radio doesn't strictly _require_ batteries -- if you
want to use it as a doorstop".

> Correct, but in practice the byte code is very close to source code.
> There are decompilers which can produce something very close to
> original source code from byte code.

I didn't want to regurgitate the entire Java Programmers' FAQ.

> The JVM is what actually executes Java byte code.  A JRE is JVM plus
> associated libraries.

You'll have to take that up with the Java people, who seem to disagree
with you (although usage is somewhat inconsistent).  See, for example,
Blackdown's Java Linux FAQ, question 2.2.

If you have not yet come across that inconsistency of usage, look
further, and I think you will.  But I merely reported what I
encountered:  "JVM" tends to refer to a software-bundle _superset_ of
the bare runtime interpreter + essential libs (i.e., the virtual
machine, in the abstract sense) with some other developer tools.

> There are just-in-time compilers and ahead-of-time compilers.

Distinction noted.  (In fact, I already cited gcj as an example of the
latter.)

> Sun has no objection to JIT compilers, in fact they produce their own
> (called Hotspot).

I was aware of HotSpot, but didn't list it because (to repeat, yet
again) I was concentrating on open-source Java tools.  But the wording I
quoted, objecting that JITs "destroy portability, which is one of the
main benefits of Java" is pretty much the standard Java-camp party line,
as articulated by Peter van der Linden and other maintainers of the Java
Programmers' FAQ.  (I didn't say it made sense, just that it's what they
claim.)  

Possibly I erred in attributing that view (these days) to Sun itself.

===

Date: Wed, 08 Aug 2001 03:20:14 -0700
From: Jeffrey Siegal <jbs@quiotix.com>
To: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] Netscape 6.01

Rick Moen wrote:
> > Only if the program uses such libraries, and/or if you want to execute
> > the compiled program.
> 
> Sort of like "the radio doesn't strictly _require_ batteries -- if you
> want to use it as a doorstop".

Not exactly.  Particularly in a networked environment, it is not unheard
of to compile code on one system and use it on another.  If are writing
code that uses libraries, and won't be executing it on the system that
you compile it on, you don't need libraries.  

> > The JVM is what actually executes Java byte code.  A JRE is JVM plus
> > associated libraries.
> 
> You'll have to take that up with the Java people, who seem to disagree
> with you (although usage is somewhat inconsistent).  See, for example,
> Blackdown's Java Linux FAQ, question 2.2.

That does not contradict what I wrote at all.  In fact it agrees with.

> If you have not yet come across that inconsistency of usage, look
> further, and I think you will.

I don't doubt there is erronous information out there somewhere, but
that's what it is.

> But I merely reported what I
> encountered:  "JVM" tends to refer to a software-bundle _superset_ of
> the bare runtime interpreter + essential libs (i.e., the virtual
> machine, in the abstract sense) with some other developer tools.

That's just wrong.

> > Sun has no objection to JIT compilers, in fact they produce their own
> > (called Hotspot).
> 
> I was aware of HotSpot, but didn't list it because (to repeat, yet
> again) I was concentrating on open-source Java tools.  But the wording I
> quoted, objecting that JITs "destroy portability, which is one of the
> main benefits of Java" is pretty much the standard Java-camp party line,
> as articulated by Peter van der Linden and other maintainers of the Java
> Programmers' FAQ.  (I didn't say it made sense, just that it's what they
> claim.)

Not as far as I can tell.  They make that claim with respect to
ahead-of-time compilers (compiling to an executable image), not JIT
(which, when correctly implemented, should be completely portable and
transparent, just faster, but see below):

"(Sect. 4) Can I compile a Java program to a binary executable, .exe on
a PC? 

 Compiling into native code destroys portability, which is one of the
main benefits of Java. ...  "

Later, the FAQ specifically applauds the HotSpot JIT, saying it "rocks":

"(Sect. 4) How do I turn off the JIT in the JDK? ... The main reason for
turning off the JIT is to get more information about any exception that
is thrown in your code. But HotSpot is able to produce line numbers in
stack traces even for JIT'd code. HotSpot rocks."

> Possibly I erred in attributing that view (these days) to Sun itself.

You appear to just be confused about the terminology used in the Java
community.  Probably this is due to reading bad information on the net,
which is rampant.  I'm happy to help clear up any such
misunderstandings. (I've been involved with Java development, on and
off, for five years now.)


===


Date: Wed, 8 Aug 2001 09:07:50 -0700
To: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] Netscape 6.01
From: Rick Moen <rick@linuxmafia.com>

Jeffrey Seigal wrote:

> If are writing code that uses libraries, and won't be executing it on
> the system that you compile it on, you don't need libraries.  

I neither write nor compile Java source -- as I find the
language a rather wretched and inappropriate tool for most
purposes it's perversely applied to, regardless of the
toolkit -- but those who do, tell me that javac (or
equivalent) needs to be able to find libraries that are
referenced in the source, or it won't work.

If you have magic compilers that don't mind referenced libs
not being present, bully for you, but I'm sick of this.

> That does not contradict what I wrote at all.  In fact it agrees with.

Re-read.

> I don't doubt there is erronous information out there somewhere, but
> that's what it is. [...] That's just wrong.

Gee, I'm sorry: You'll have to argue with the Java
programmer community, not me.  I don't have time for this.

[Considerable further gnawing the bone of Sun Microsystems's
attitude towards JITs acknowledged but not discussed, as it
was really not relevant to the prior discussion.]

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu