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

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

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.

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