|
|
Subscribe / Log in / New account

Some notes on free Java

The free software community would appear to have developed a winning strategy for bringing semi-proprietary code under a free license. Just create a project to reimplement that code, and name the project "Harmony." About the time that the Harmony project starts to make some real progress, the original code base will be relicensed to the GPL, and everybody will be happy.

This approach worked well with the first Harmony project, which was created to make a free version of the then-proprietary Qt library. In September, 2000, Trolltech finally made Qt available under the GPL. More recently, a Project Harmony set out to create a free Java implementation. A year and a half later, Sun Microsystems finally let go, and has promised to release Java as free software - and under the GPL at that.

Clearly some serious thought needs to be put into picking an appropriate target for the next Harmony project.

Actually, the "Harmony" name may not become available for a while yet; a quick look at the mailing list shows that, unlike the previous Harmony project, the current Harmony developers are continuing full-speed with their work. One might well wonder why, given that the "real" Java code is now promised to the community. It may be partly a matter of momentum, and partly waiting until the code actually becomes available (it will be a few months yet). Sun's interesting choice of the GPL also appears to be relevant. The Harmony project, being under the Apache umbrella, is using the Apache license, which is not compatible with the GPL. So the Harmony developers will not be able to make use of Sun's code in their project. If they want an Apache-licensed Java, they will have to continue to work to create it themselves.

There appears to be some concern within Harmony that Sun will require copyright assignments from those who would contribute to the GPL code base, and that, in turn, would allow Sun to make use of contributed code in proprietary projects. There are Harmony developers who are unwilling to contribute under those conditions. It has also been suggested in the Harmony camp that Sun might use patents to enforce Java compatibility. So Harmony may well continue for a while.

Another project which will be affected by this release is GNU Classpath. Unlike Harmony, however, Classpath uses a "GPL plus exception" license which allows the use of the library in proprietary applications. Sun's choice of the GPL makes life easy for the Classpath developers - especially since Sun adopted the same exception. But it does leave open the question of whether Classpath is needed at all. The real answer there probably depends on the shape of the actual code release; there may be parts of the "real" Java class library which Sun is unable to release, and which might then be substituted from Classpath. It also seems that Classpath has managed to build a dynamic and effective development community; the desire to continue to develop in that environment may keep Classpath going for a while yet.

Many pixels have been expended in attempts to analyze Sun's choice of the GPL. Most likely, Sun went with the GPL because (1) the response to the CDDL has been lukewarm at best, and (2) experience shows that GPL-licensed code is relatively resistant to the creation of incompatible forks. Sun's ostensible reason for resisting free licensing all these years was a fear of incompatible versions, so fork resistance should have been on their minds. Also worthy of note is the fact that Sun has specified that it is using version 2 of the GPL. A switch to GPLv3 seems likely once the license is final (see Jonathan Schwartz's weblog), but Sun is not committing to that ahead of time.

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. There must be useful code within Solaris, even if some of the more interesting parts (the ZFS filesystem, say) would be a major challenge to port.

In any case, Sun's freeing of Java is a significant - if a bit overdue - gift to the community. It will enable the Java language to become a first-class citizen within Linux distributions and make a powerful language fully available to free software developers. Sun certainly cannot be faulted for failing to contribute in recent years. Soon, it will be up to the community to take this code and do great things with it.


to post comments

stretching logic to make a "cute" point?

Posted Nov 16, 2006 5:59 UTC (Thu) by stevenj (guest, #421) [Link] (4 responses)

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.

stretching logic to make a "cute" point?

Posted Nov 16, 2006 9:28 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

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?

Posted Nov 16, 2006 11:11 UTC (Thu) by gravious (guest, #7662) [Link]

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.

stretching logic to make a "cute" point?

Posted Nov 16, 2006 19:46 UTC (Thu) by k8to (guest, #15413) [Link]

I think it was obviously a humour value statement.

stretching logic to make a "cute" point?

Posted Nov 17, 2006 14:11 UTC (Fri) by coriordan (guest, #7544) [Link]

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

Some notes on free Java

Posted Nov 16, 2006 9:38 UTC (Thu) by ewan (guest, #5533) [Link] (2 responses)

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

Some notes on free Java

Posted Nov 16, 2006 19:52 UTC (Thu) by k8to (guest, #15413) [Link] (1 responses)

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

Some notes on free Java

Posted Nov 23, 2006 16:19 UTC (Thu) by robilad (guest, #27163) [Link]

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

Posted Nov 16, 2006 16:18 UTC (Thu) by dwheeler (guest, #1216) [Link] (7 responses)

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.

Currently Sun can't release some pieces

Posted Nov 16, 2006 17:57 UTC (Thu) by mikov (guest, #33179) [Link] (6 responses)

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

Posted Nov 16, 2006 21:13 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (5 responses)

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?

How JITs can outperform static compilation

Posted Nov 16, 2006 21:24 UTC (Thu) by PaulMcKenney (✭ supporter ✭, #9624) [Link] (2 responses)

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.

How JITs can outperform static compilation

Posted Nov 18, 2006 13:07 UTC (Sat) by job (guest, #670) [Link] (1 responses)

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.

How JITs can outperform static compilation

Posted Nov 18, 2006 18:10 UTC (Sat) by mikov (guest, #33179) [Link]

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.

Currently Sun can't release some pieces

Posted Nov 16, 2006 21:35 UTC (Thu) by mikov (guest, #33179) [Link] (1 responses)

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

Currently Sun can't release some pieces

Posted Nov 23, 2006 13:03 UTC (Thu) by irios (guest, #19838) [Link]

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?

Some notes on free Java

Posted Nov 17, 2006 14:20 UTC (Fri) by coriordan (guest, #7544) [Link]

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.


Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds