So what is the first thing you try out on your little bare arm board when you get IcedTea, Cacao and gcjwebplugin working? You try to play slime volleyball of course!

Read all about it on Xerxes Rånby’s blog.

Just saw A Lazy Developer Approach: Building a JVM with Third Party Software by Nicolas Geoffray, Gael Thomas, Charles Clement and Bertil Folliot. They show something I always found super cool about the community around GNU Classpath and the free software community in general. Working together on parts of free software to enable everybody to stand on top of the shoulders of giants.

The development of a complete Java Virtual Machine (JVM) implementation is a tedious process which involves knowledge in different areas: garbage collection, just in time compilation, interpretation, file parsing, data structures, etc. The result is that developing its own virtual machine requires a considerable amount of man/year. In this paper we show that one can implement a JVM with third party software and with performance comparable to industrial and top open-source JVMs. Our proof-of-concept implementation uses existing versions of a garbage collector, a just in time compiler, and the base library, and is robust enough to execute complex Java applications such as the OSGi Felix implementation and the Tomcat servlet container.

They have some nice things to say about GNU Classpath and our VM Interface

Industrial JVMs often have their own implementation of garbage collection, compilation, interpretation and class libraries. Open-source JVMs tend to all use the GNU Classpath base library implementation [6] (some JVMs are currently being ported to the newly open-sourced Sun implementation), and the Boehm garbage collector [22]. GNU Classpath and Boehm GC are popular among JVM implementations because they are virtual machine agnostic, hence they do not depend on a particular JVM implementation.

[...]

We started the project with GNU Classpath version 0.93. LadyVM now uses the latest version, 0.97.2. Since GNU Classpath has had many releases before 0.93, the API changes between 0.93 and 0.97.2 were minimal.

GNU Classpath moved to java version 1.5, including generics, with release 0.95. Since the JVM specification did not change between version 1.4 and 1.5, the move to GNU Classpath 0.95 did not require any changes in LadyVM. The only modification we made was due to the ldc opcode, which loads classes since JVM 1.5.

So next time you want java somewhere, just pick up the free software pieces already there and click them together for your environment :)

Things that make you smile:

From: Matthias Klose
To: debian-68k@lists.debian.org
Subject: building openjdk-6 for m68k

the openjdk-6 6b11-4 should build on m68k. It may take a few weeks, but I currently don’t see any issue with it. If you do so, please keep the build tree, so that the testsuite can be run, after the build finishes (taking some more weeks to finish).

It is a pure IcedTea Zero interpreter for Hotspot build (unfortunately the cacao m68k jit is currently “broken” :{ ), which explains the long, long, long build time. But if you have some spare m68k machine around and a couple of spare weeks, please do give it a try.

You would hope that Sun would get it by now, but apparently not :{

From the new JavaFX license:

“Licensee is not authorized to modify, make derivative works of, disclose, distribute, reverse engineer or disassemble the Technology, decompile binary portions of the Technology, or otherwise attempt to derive source code from such portions, or transfer the Technology to any third party or use it in development activities.”

“Licensee shall have no right to use the Technology for commercial uses or in a production environment.”

“Java Technology Restrictions. You may not create, modify, or change the behavior of, or authorize your licensees to create, modify, or change the behavior of, classes, interfaces, or subpackages that are in any way identified as “java”, “javax”, “javafx”, “sun” or similar convention as specified by Sun in any naming convention designation.”

Sigh.

Update It gets better:

“It is understood and agreed that, notwithstanding any other provision of this Agreement, Licensee’s breach of Sections 2.0 (Limited Licenses), 3.0 (Restrictions), 6.0 (Term and Termination), and/or 7.0 (Confidential Information) of this Agreement will cause Sun irreparable damage for which recovery of money damages would be inadequate…”

It is as if someone from Sun Legal was reading the Ubersoft episodes Grand Design and Ultimate Goal while drafting this license.