LWN: Comments on "Some notes on free Java"

Some notes on free Java

robilad — Thu, 23 Nov 2006 16:19:47 +0000

There is something mildly ironic about folks pitching a project to create a free Java implementation on the basis of being easily able to turn the resulting code into a proprietary implementation. ;)

Currently Sun can't release some pieces

irios — Thu, 23 Nov 2006 13:03:46 +0000

I was also going to point out that, in my Ubuntu installation, Eclipse launches more than three times slower with gcj than with Sun Java, and then it feels a lot *more* sluggish.

But then I thought that the 3X acceleration was obtained simply by choosing Sun's jvm to execute *the same Eclipse code*, so it has downed on me that I must have never run Eclipse compiled to native with gcj, but *interpreted* java code ran with the gcj interpreter, which nobody in his right mind has said is fast.

Are you sure that you have tried *native* Eclipse?

How JITs can outperform static compilation

mikov — Sat, 18 Nov 2006 18:10:12 +0000

Hate to burst your bubble, but a static compiler cannot make dynamic optimizations. Perhaps only in some trivial cases, with the cost of extreme code duplication.

The notion that a JIT can universally outperform a static compiler for languages like C or Fortran is certainly hype. However it is _not_ hype for Java. In all my tests HotSpot and IBM's JVM outperform GCJ for typical Java code with a significant margin - often 2x.

Note that typical Java code has lots of allocations, lots of pointer chasing, lots of non-reducible virtual method calls, etc. Look at this completely trivial Java code:

   
int sum ( Collection<Integer> c )   
{   
  int res = 0;   
  for ( Integer x : c ) res += x;   
  return res;   
}

It is completely unoptimizable statically. The difference between a Java-oriented JIT and GCJ will be overwhelmingly in favor of the JIT.

How JITs can outperform static compilation

job — Sat, 18 Nov 2006 13:07:50 +0000

That's the hype, anyway. I've never seen it actually run faster, except in rigged benchmarks.

To be fair, a native compiler could use dynamic optimizing techniques as well. It's just that they're not mature enough yet.

Some notes on free Java

coriordan — Fri, 17 Nov 2006 14:20:07 +0000

Another advantage of GNU Classpath's work is that it has trained a team of free software hackers to be experts in Java. I'm sure some or most of their work will find a place in the future of free software, but even if it didn't, the developers will.

stretching logic to make a "cute" point?

coriordan — Fri, 17 Nov 2006 14:11:28 +0000

I think the "Harmony" replacement for Qt was also not so complete - it was more GNOME that pressured Trolltech to use a GPL-compatible licence.

...but I still like the note about the name "Harmony".

Currently Sun can't release some pieces

mikov — Thu, 16 Nov 2006 21:35:22 +0000

This is a complicated question and I don't remember all the details, but
basically the very nature of Java doesn't allow good static optimization.
For example too many method calls are virtual and the exact object type
cannot be deduced at compile time. A JIT, on the other hand, can
conditionally inline a virtual method, it can generate several specialized
versions of the code, etc. When you inline a method, many optimizations
cascade from that.

Recently it is becoming increasingly popular in Java to generate
executable code at runtime. It is a very powerful technique. A static
compiler can't deal with it well without incorporating a JIT in its
runtime library.

Lastly, even though GCC has a decent backend, in my tests Eclipse compiled
with GCJ is too slow to be usable (well, at least on an Athlon XP 2000).

GCJ has still has room for improvement though. I am not sure whether they
have already implemented Java-specific optimizations like removing
redundant range checks, moving interface lookups out of loops, etc. That
should give it a nice boost. More improvement can come from heavy
profile-guided-optimization and whole-program-optimization, but it is a
very complicated area (and whole-program-optimization isn't really
possible for Java anyway).

How JITs can outperform static compilation

PaulMcKenney — Thu, 16 Nov 2006 21:24:14 +0000

Because the JIT can take dynamic conditions into account, producing code that is optimal for the specific workload in question -- and regenerating the code if the workload should change, even during a single run of the program.

Currently Sun can't release some pieces

tzafrir — Thu, 16 Nov 2006 21:13:36 +0000

Why should code "compiled" with a good JIT JVM run inherently faster than a code built with a good optimized static compiler that had much more time for various optimizations?

Some notes on free Java

k8to — Thu, 16 Nov 2006 19:52:02 +0000

> > ...would allow Sun to make use of contributed code in proprietary
> > projects. There are Harmony developers who are unwilling to
> > contribute under those conditions.
>
> That seems like a bizarre point for the Apache people to make since
> a number of them have been vocally advocating their licence specifically
> because it allows the creation of proprietary forks and the GPL doesn't.
> Also; if anyone doesn't like assigning copyrights to Sun they don't have
> to do it - Sun won't accept their changes into Sun's codebase, but if
> you're prepared to run a complete parallel project anyway you might as
> well use Sun's code in it. If Sun don't want to accept your changes
> back, that's Sun's loss, it doesn't harm the Free software project.

Well, if your goal is to be able to "commercialize" ie. close, the
free software project you are working on at some future point, then
there is a difference. Assigning copyright to Sun allows to use it
in proprietary ways, but not you. Working on your own BSD or Apache
license Java allows anyone to use it in proprietary ways. You could
care about this because you have some moral view that anyone should
be able to make closed forks of open code. I've heard this view
before, although only from people who have done so (c2.net springs
to mind). There may be others. You could also care about it because
you plan to do this yourself.

stretching logic to make a "cute" point?

k8to — Thu, 16 Nov 2006 19:46:13 +0000

I think it was obviously a humour value statement.

Currently Sun can't release some pieces

mikov — Thu, 16 Nov 2006 17:57:15 +0000

I am nitpicking really. You mentioned that gcj is useful for speed. In
fact gcj compiled code is slower than code running under Sun
JVM. Due to the nature of the Java language, I suspect that a static
compiler can never outrun a HotSpot-like JIT.

It has to be said though that Java applications compiled with gcj start a
lot faster, have less dependencies, have much more predictable execution
speed and are much easier to integrate with C. So, gcj will remain very
useful, only not for the speed of the code it produces.

Currently Sun can't release some pieces

dwheeler — Thu, 16 Nov 2006 16:18:15 +0000

The FAQ on Sun's release of Java notes that there are some 3rd-party software components that Sun can't release; these affect 2D graphics in particular. If that can't be worked out, then pieces of Classpath will be needed to fill in Sun's own Java implementation.

That said, it's a lot easier to fill in small pieces, given that there's another implementation with a compatible license, than to implement the entire Java class library. In the end there will be at least one FLOSS Java class library (and likely two) and at least two FLOSS Java implementations (gjc for speed, and Sun's for broad functionality). This is really great!

I think we'll see at least a small uptick in Java usage because of this. The real question is whether there will be a large uptick. It's definitely possible; Java has been held back for years due to Sun's inept licensing policies, and though they've lost many years, perhaps they'll manage to regain it.

stretching logic to make a "cute" point?

gravious — Thu, 16 Nov 2006 11:11:02 +0000

Um, i replace gcj with sun's java in Ubuntu every time because Eclipse, Limewire & more barf when they use GNU's stuff. When it comes to stuff like this, above 90% is not good enough - no offence. I'm not dissing GNU Classpath, I'm just saying from my experience apps I want to run, run badly. You obviously have never used Eclipse or you have used it without loading any extra plugins. Maybe oo.org works with gcj stuff but considering who owns oo.org now it would seem dumb not to use their own java technology too. Yeah - it's been non free but it's not like murdering babies.

Some notes on free Java

ewan — Thu, 16 Nov 2006 09:38:03 +0000

...would allow Sun to make use of contributed code in proprietary projects. There are Harmony developers who are unwilling to contribute under those conditions.
That seems like a bizarre point for the Apache people to make since a number of them have been vocally advocating their licence specifically because it allows the creation of proprietary forks and the GPL doesn't. Also; if anyone doesn't like assigning copyrights to Sun they don't have to do it - Sun won't accept their changes into Sun's codebase, but if you're prepared to run a complete parallel project anyway you might as well use Sun's code in it. If Sun don't want to accept your changes back, that's Sun's loss, it doesn't harm the Free software project.

It has also been suggested in the Harmony camp that Sun might use patents to enforce Java compatibility
Depending on how trivial and broad the supposed patents are, there's no guarantee that reimplementing the code independently is going to avoid infringing them. At least using Sun's code would allow a defence of having a patent licence implicit in the GPL.

Sun has made some hints that Solaris might move over to the GPL as well. This would be a significant change, as it would allow Solaris code to find its way into the Linux kernel.
Not necessarily. If Sun wait until the GPLv3 is finished and then move to that it will remain incompatible with the GPLv2 licence that Linux as a whole is covered by. It would, however, allow the use of those portions of Linux licensed as 'v2 or later' to be used in a GPLv3 Solaris.

stretching logic to make a "cute" point?

drag — Thu, 16 Nov 2006 09:28:57 +0000

Ya..

They have compatability above 90% for most of Classpath, I beleive. And most major open source projects that use java can also use the GCJ stuff.

For example: Openoffice.org, Eclipse, Azereus.

Most other stuff like that. So right now Classpath is a real viable GPL Java implimentation. I don't know anything about Harmony, it seems as a 'also ran'. To me the 'real' open source Java stuff has always been the GNU Classpath stuff, after all it's actually usefull and can be used _right_now_.

It also looks to me that most of the Classpath folks tried to join in on the Harmony stuff, but it couldn't work out due to Apache's very inflexible licensing requirements.

It would seem to me that, logically, what will end up happenning is that GNU folks will work with Sun to 'fill out' Sun's GPL'd java and then start working on GPL-compatable replacements and improvements for commonly used Java libraries and such rather then continue work on Classpath.

After all Java is a lot more then just the VM. It's all the libraries and third party stuff that makes it what it is, I expect there will still be a lot to work todo to make Java a first-class programming language for GNU/Linux. (and I don't mean that in the RMS-manner either.. I mean the 'GNU community' and the wider 'Linux community' including Apache and commercial stuff (and maybe even a little bit of the propriatory stuff)).

stretching logic to make a "cute" point?

stevenj — Thu, 16 Nov 2006 05:59:45 +0000

In order to make your little play on words about projects named "Harmony", I suspect that you gave too much credit to the Apache Harmony project and too little credit to the Classpath project — even though Classpath is both far older and (by all appearances) far more complete and influential than Harmony.