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

Re:Better for the Linux User

[Chris Kamel]

Don't you think a reimplementation of the VM is too much of a price to pay for such a small convenience?

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.

binary compatibility?

[palinurus]

I bet they can pull off a really nice VM. The existence of multiple VM implementations has yet to produce the kind of community fragmentation that a lot of people have prophesized, is a credit to the strength of sun's spec writing, and has been good for the platform overall (my java apps, both client and server, run without modification on os x...) I wonder about the class libraries, though.

It seems like maintaining binary compatibility between serialized classes (esp. for collections and java.lang classes) is essential, at least if you want to do J2EE stuff in the long run. It will be at least a nuisance to, say, reimplement java.util.HashMap in a binary-compatible way without illegally appropriating Sun's IP (something the project seems pretty conscious of in their charter/FAQ).

It's not impossible, but I think the IP challenge there is the real issue (not to mention the fact that your implementation is going to be constrained to being nearly identical to Sun's, at least in terms of overall strategy, if not line-by-line). If you read Sun's code in one window, and then write the same member variables in the same order in another window, is that copying code or not? And even if you do write something completely different (say, going with the HashMap example), you have to come up with some kind of transformation from your choice of state variables to sun's serialized state variables, which could look pretty nasty.

I also pity the poor bastard that has to write those AWT libraries...

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.

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?

Interesting project name..

[salimma]

.. does anyone else get a déja vù from the KDE-sponsored attempt to clone Qt back in the non-QPL 1.x days?

Re:great news

[AstroByte]

Most of your points are right, however, I take issue with the statement that the bytecode loop is trivial. This, I'm afraid, is a widely held misconception :)

While a simple switch-based interpreter is trivial to implement, it will perform abysmally on modern processors because of the overhead of the computed jumps. Writing an efficient interpreter has been an active research area in itself (see http://www.complang.tuwien.ac.at/projects/interpre ters.html for some good papers). In fact, the difference between a poor interpreter and a good interpreter can be greater than that between an intepreter and a JIT.

Several improvements over a switched interpreter are possible. Firstly, indirect-threading can be used to minimise dispatch overhead. This can further be improved by moving to direct-dispatching, but this requires rewriting the original bytecode stream. Splitting instruction fetch and address computation via prefetching can also lead to substantial gains, as can the use of "super-instructions".

Additionally, an interpreter can attempt to do stack-caching (either simple top-of-stack caching or more advanced 2 or more levels). This can be used to overcome the inefficiency of executing stack-based bytecodes on a register-based CPU.

Many of these techniques move into the grey area between interpreters and JIT compilers. But no commercial VM uses a simple bytecode interpreter. Even with a JIT, modern VMs still initially execute code using the interpreter, only compiling the "hot spots" to native code. With full JIT compilation, the start-up time of the VM becomes prohibitive.

Many of these techniques are also used in some of the open-source VMs. For example, the interpreter in JamVM, depending on architecture, makes use of direct-dispatching, super-instructions, prefetching, and true, 2 level stack-operand caching. It is many times faster than a simple bytecode interpreter, and it has not been trivial to implement!