Slashdot Mirror
On the Horizon: an Apache-License Version of Java
mparaz writes "Geir Magnusson of the Apache Software Foundation announced a J2SE 5 implementation project called 'Harmony.' It covers the virtual machine and the class libraries, and aims to pass the Sun specification.
A FAQ is available."
For those too lazy to click through to that blog entry, Kaffe, Classpath and other solutions already exist, and this is not the first.... although coming from Apache carries some weight.
Simpy
I remember a project called Harmony that had the purpose of being an API-compatible clone of QT but without the license issues: www.kde.org/whatiskde/qt.php. It never got off the ground though.
see a Text Widget
It still couldn't be part of OpenBSD though, because of the new more restrictive Apache licence 2.
In the mean time, the Apache group's choice of license for their Java project makes perfect sense given a major, if not the major, use for Java these days is for back-end work of web-fronted applications. Apache's Tomcat sometimes seems to be more popular than Apache itself. (I said seems people, seems); I can't think of any other reason why the Apache people would be organizing this, though it surprises me they're going for J2SE and not J2EE compatability.
So, no. There's no "Java trap" inherent in developing code for Apache Harmony.
You are not alone. This is not normal. None of this is normal.
Then there are the class libraries, which have sprawled to a massive scale, and in comparison make implementing the JVM look easy. Look at Wine, which still isn't an alternative for Win32 (only selected applications are supported), after years and years of work. Or Mono, which cannot and probably never will run arbitrary .Net apps.
I can't think of any other reason why the Apache people would be organizing this, though it surprises me they're going for J2SE and not J2EE compatability.
But they are. J2EE is a superset of J2SE, and by adding Apache Geronimo you'd get the complete stack. Admittedly Geronimo is aiming for J2EE 1.4 rather than J2EE 5.0 at the moment, but J2EE 5.0 doesn't really exist yet. ;o)
The truth is the opposite of your stance. Apache wants a free Java because an enormous amount of back-end web code these days is written in Java. As such, they need a Java interpreter that "plays well" with Apache. That means something licensed under the ASL2, which, like the GPL, is a Free Software license.
If they licensed it under the GPL, then the question of how well it could legally integrate with Apache would come up.
Long term the solution to this almost certainly lies in the GPL3, which will alleviate many of the issues that forced the Apache people to put together an alternative license to begin with. But for now, looking at the circumstances, this is one of those rare cases where a license that happens to be incompatable with the GPL is appropriate.
(And, FWIW, I speak as someone accused of being a GPL zealot on a regular basis. I love the GPL. For most projects, providing the GPL as the license or a license a user can choose as an alternative, seems absolutely appropriate.)
The ASL2 is a Free Software license. It's not compatable with the GPL, and incompatabilities do undermine freedom, but when choosing between it and the GPL, you have to look at what critical code it will have to interact with. Had they choosen the GPL, it would arguably have undermined freedom far more than the choice they made.
If you want GPL compatable Java, take a look at GCJ and GNU Classpath. There are people working on both these and Harmony. They are cooperative. This project is helping freedom, not working against it.
You are not alone. This is not normal. None of this is normal.
"C++ -- I'm not qualified to comment on that."
C++ also have an ANSI standard. So, if you code following ANSI C++ and POSIX, your program should run on every unix (and NT). But C++ compilers are known to not following standars, so it is not that good.
Rethinking email
Right, but so what? It can "run" .class bytecode files by compiling them to native code on the fly, this is how gcjwebplugin works AFAIK. The difference between a VM and compiler is mostly one of semantics, there's no compelling enough reason to reimplement the VM.
No JIT, though. Which makes it nearly useless on the server, where Java is mostly used.
Actually a JVM is trivial -- it's the class libraries that are difficult. On the JVM front there is Kaffe, Jikes (the JVM bit, not just the javac bit), ikvm, etc. That's just the ones I can remember how to spell. Class libraries however is pretty much restricted to the Sun one and the GNU (attempt at) one.
Good idea, but i think Parrot is designed for dynamically-typed lanuages (perl, python, ruby), wheras java, c# are statically typed.
Why your own virtual machine? Why not compile to JVM/.NET?
http://www.parrotcode.org/faq/
Fortunately Sun does let us fix bugs now.
Take a look at this article:
I fixed the JDK!
This guy submitted code fixes and actually got accepted by Sun and rolled into Mustang code!
www.rexguo.com - Technologist + Designer
The bytecode loop and elementary classloader are indeed straightforward (which is why there are so many of them hanging around), and doesn't really get harder between a barely-working JVM and a decent one. Lots of other stuff, however, does:
- A dumb, blocking, non-generational mark-and-sweep garbage collector is fairly straightforward (handling blocking and native methods wrt GC is a complication, if a manageable one). But for a box serving lots of connections on a busy website, you don't really want half second long pauses while the GC sweeps the whole memory. You really need a generational collector, and you really want one that's either non-blocking (yes, that's hard) or resumable. The nice thing is that the GC is fairly self contained (not entirely, as it interworks with synchronisation and the native method interface) and there are lots of university research groups who have done lots of research on GCs (for java and other languages) so it should be possible either to pick up some research collector or farm the work out to some eager masters students.
- Efficient management of native synchronisation resources has an important effect on scalability. Mature JVMs go to great lengths to marshall the number of native synchronisation primitives the JVM instance uses (e.g. with some kind of mutex pool, assigning an OS mutex to a java one only when it is in scope). They can work without this for a while, but it needs done eventually. I see Doug Lea is onboard, and this kind of stuff is Doug's meat-and-drink.
- The verifier is hard to get right. Sun's one is the product of careful design and then of several analyses by third parties. For example, one univerity wrote a verifier from the JVM spec in a formal language (Z or something) and then threw millions of randomly generated program fragments at their one and the Sun one. Where the two differed, the group analysed the program in depth. From this they found dozens of cases where the two verifiers differed materially; most were due to different interpretations of the JVM spec (which, one hopes, resulted in the language of the spec being tightened) but about ten were nontrivial holes in the Sun verifier. Last time I was involved with this (a few years ago) Sun insisted that all Java licencees (even those who had written their own JVM etc. entirely from scratch) run the Sun verifier. Luckily, the verifier is like the GC - it's a subject of ongoing academic research, so there are universities who might be persuaded to do the heavy lifting. And for a trusted enterprise setup you can do without the verifier anyway (it's really only needed for untrusted mobile code like applets or JINI things).
- But the really big task is dynamic compilation. A bytecode-interpreted system isn't credible for any real application. A JIT will do, at the expense of sluggish performance and drastic memory-munching. A real hotspot-like smart, self-monitoring dynamic compiler is really necessary for a quality JVM. I guess the Harmony folks will spend a lot of effort here, as it's a lot of work and its too tightly bound to your JVM internals to either farm out or to allow you to easily take something off the shelf.
Still, I hope I've not sounded too negative. It's all doable (python and mono do most of this stuff between them, neither with a vast team) and the lack of a free or open JVM has been an uncomfortable gap between LAMP and tomcat for too long.Heck, maybe it's just a strategy to get Sun to open Tiger sooner rather than later.
## W.Finlay McWalter ## http://www.mcwalter.org ##
I believe that gcjwebplugin actually uses gij to interpret the byte code. The standard libraries are compiled to native code, but the applet classes aren't.