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

Comments

great news

[Sv-Manowar]

Could this be an essential aid to Tomcat and the increasing number of projects the apache foundation are managing within the Java space, such as ANT. This can only be a good thing

Re:great news

[timeOday]

If it ever happens, yes... but so far it's just a message on a bulletin board. Implementing the JVM itself is no trivial task, and would take years to reach the performance and stability of Sun's JVM even with huge resources. They have chosen their own unique architecture so I don't think code reuse is in their plan.

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.

Re:great news

[wfmcwalter]

Well, an elementary JVM is trivial, but a half-decent one has some harder stuff. Assuming they'll want to get Harmony up to the standard of Apache-httpd and Apache-tomcat, the JVM component will be a big job too.

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.

Better for the Linux User

[MoogMan]

Cool! This will be useful for the majority of Linux desktops, because it means it could be installed as part of a default install, rather than having to download it and install it afterwards (==hell for lots of users).

Re:Better for the Linux User

[IamTheRealMike]

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.

Re:Better for the Linux User

[DrXym]

The same could be said for Kaffe, gcj, classpath et al. And in fact it probably has been, each in their time being heralded as a way to break from Sun.

Sadly the reality is that no Java is even remotely as reliable or complete as Sun's implementation for the desktop let alone anywhere else. Major work had to be done to gcj just to make Open Office 2.0 run, which hardly speaks for its maturity. And other impls such as Kaffe are missing critical security functionality such as byte code verification. And enterprise level functionality? Forget it.

Personally I'd love to see a free and open source Java, but its taken years to get this far and its still not there yet.

Re:Better for the Linux User

[beforewisdom]

"sneaky" ?

I really hate to defend Sun,...really, I do, but they are the ones who spent a ton of money and work developing Java.

They make it available for free of charge.

what jerks

basic architectural blueprint

[anandpur]

http://people.apache.org/~geirm/harmony.jpg

Re:Not GPL compatible

[squiggleslash]

In case you're serious, the Apache Sofware License 2.0 is considered a Free license, just not a GPL compatable one. The FSF actually quite likes it:

This is a free software license but it is incompatible with the GPL. The Apache Software License is incompatible with the GPL because it has a specific requirement that is not in the GPL: it has certain patent termination cases that the GPL does not require. (We don't think those patent termination cases are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)

It's quite probable that once version 3 of the GPL is released, there'll be a strong effort from both sides to get some compatability between the two as incompatable licenses hurt everyone, whatever your ideological differences. Version 3's important because it's the one the FSF has suggested it'll deal with the issue of patents in.

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.

Re:Divide and Conquer

[multipartmixed]

C *is* cross-platform.

The system libraries, on the other hand.. well, that has nothing to do with the language. If you want cross-platform code, use cross-platform libraries.

If you can stick to using only functions in K&R and the POSIX Programmer's Reference Guide, you will find that your code (if written properly) will run damn near anywhere.

If you want a little more functionality (as much as you need, really) without GUI, adding the Apache Runtime Library will get you there -- portably. Especially under unices and workalikes.

C++ -- I'm not qualified to comment on that.

JamVM

[Hugo Graffiti]

I hope they choose JamVM for the VM. It's a fairly new VM but impressively lean and mean (100k executable that still supports the full spec). From the JamVM web site, here is a list of the main features:

• Uses native threading (posix threads). Full thread implementation including Thread.interrupt()
• Object references are direct pointers (i.e. no handles)
• Supports class loaders
• Efficient thin locks for fast locking in uncontended cases (the majority of locking) without using spin-locking
• Two word object header to minimise heap overhead (lock word and class pointer)
• Execution engine supports basic switched interpreter and threaded interpreter, to minimise dispatch overhead (requires gcc value labels)
• Stop-the-world mark and sweep garbage collector
• Thread suspension uses signals to reduce suspend latency and improve performance (no suspension checks during normal execution)
• Full object finalisation support within the garbage collector (with finaliser thread)
• Garbage collector can run synchronously or asynchronously within its own thread
• String constants within class files are stored in hash table to minimise class data overhead (string constants shared between all classes)
• Supports JNI and dynamic loading for use with standard libraries
• Uses its own lightweight native interface for internal native methods without overhead of JNI
• JamVM is written in C, with a small amount of platform dependent assembler, and is easily portable to other architectures.

Re:JamVM

[shutdown -p now]

No JIT, though. Which makes it nearly useless on the server, where Java is mostly used.

Re:Kaffe, Classpath...

[Fefe]

Had you bothered to read the blog entry yourself before commenting, you would have noticed that Kaffe and Classpath members are part of this project.

This does appear to be a consolidation project. We have several contenders for Open Source JVMs under Linux, but most of them lack in some way or the other compared to the Sun and IBM JVMs. So having one up-to-date one instead of five not-quite-there-yet ones is a step forward.

Harmony could use Parrot

[mattr]

I'm just someone not involved in language development, and so I'm sorry if I'm out of line. Most developers in language X just sit back in admiration at the olypmian efforts of language, compiler, vm or kernel designers. But I would like to humbly suggest that Harmony people talk with the parrot people. Parrot already has a java bytecode converter proof of concept, initial code, will run on tons of platforms, and has perl and python people too. It is GPL compatible and licensable under the Perl Artistic License.

The reason I suggest this is that it would appear that the main purpose of the Harmony project is to create a vibrant, inclusive community. In that case, the open source world, Harmony, and Parrot, plus users of java, perl, python, ruby and tcl (for starters) can all benefit by combining two disparate groups of all-star programmers working in potentially complementary areas.

If any parts of the Harmony project can use parts being developed for Parrot, much time would be saved and the quality of both projects could increase. In addition, it would likely be easier for the Harmony project to meet its stated goals of collaboration and sharing of runtime components, etc. to do so with parrot. The Parrot FAQ also talks a bit about VM development, including working with a JVM, it sure sounds like there is some overlap with Harmony.

Perhaps the Parrot people don't need any help (I doubt they would say so though) and maybe the Harmony VM people can't stand the idea of not building from ground zero, or using only the Apache license and nothing else. If any of these three maybes are true then it is a sad story.

Also, I may be out of line but it sounds like parrot will enable sharing of code from different languages at runtime. If so that will just magnify what Harmony is trying to do in terms of bringing people together.

So humbly I would like to say that the ideas of creating a specification and reference implementation, and promoting collaboration and sharing of modular code sounds wonderful, and focusing on these and not wasting time reinventing the wheel could be a great move for Harmony, and contribute to refocusing the brainpower of the free software world, in the spirit of the Harmony and Parrot projects.

My guess is that Harmony has some really smart people and they are also well aware of the Parrot effort. Maybe some are already involved for all I know. Any comments one way or the other?

Re:Divide and Conquer

[Master of Transhuman]

I shouldn't have posted above while I had mod points, since this troll crap is modded "Insightful" by the Windows trolls moderators and other idiots.

Look, stupid, this is not just a "licensing fetish" (although as has been discussed, there is a perfectly good reason for Apache to not use the GPL or like Sun's license.)

The point of this project is to provide a compatible free Java that Apache can use to underpin its numerous Java-based projects.

It's an excellent idea - unless Sun ever comes out with a truly OSS license. And if they do, it will probably be because such a project is gaining traction.