Assemble your java from free standard pieces

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

Calling all m68k volunteers…

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.

The JavaFX Trap

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.

Jonas

Jonas

Fedora and OpenJDK

Andrew Haley and Thomas Fitzsimmons wrote a really nice article for Red Hat Magazine called Open source project: OpenJDK detailing our libre java journey from the perspective of Fedora and Red Hat. From Sun’s first announcement, GNU Classpath & GCJ, bootstrapping IcedTea, gcjwebplugin, webstart, PPC and the zero port, OpenJDK6, to being (almost) Java SE Compatible. Go read it!

Fedora 9 openjdk update is awesome

When you upgrade to Fedora 9, make sure you get the zero-day update of icedtea/openjdk that Lillian made. It includes some sound fixes, Gervill midi support, the hat tool and fixes for javaws/netx. Then try out Jake2 (GPLed Quake engine in Java using Jogl and Joal). Just click that Jake2 webstart link, it will just work out of the box. Awesome!

Jake2
Fedora 9

The GPL is like a green envelope

German court tells Skype to obey the GPL:

“If a publisher wants to publish a book of an author that wants his book only to be published in a green envelope, then that might seem odd to you, but still you will have to do it as long as you want to publish the book and have no other agreement in place.”

Fedora IcedTea/OpenJDK in EPEL for RHEL and CentOS

An EPEL update brought a nice surprise. The Fedora 9 IcedTea/OpenJDK packages rebuild for RHEL and CentOS on i386, ppc and x86_64. So if you are running RHEL or CentOS on your servers you can now:

$ rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
$ yum install java-1.6.0-openjdk-{devel,plugin,demo,javadoc,src}

Drop, shake and soak AWT/Swing with JamVM/GNU Classpath

Rugged PDA available with JamVM and GNU Classpath

The Nomad maintains compliance with the MIL-STD-810F standard for drops, vibration, and temperature extremes, says SDG, and is IP67 rated for imperviousness to water and dust. It can withstand 30 minutes exposure under a meter of water, says SDG, as well as survive temperatures ranging from -22 to 144 degrees F. […] Developers can create both AWT and Swing applications using the JamVM virtual machine and the GNU Classpath Libraries […] the Nomad sells for $1,650 to $2,300.

Nomad
A bit pricey, but so cool! :)

Down LWN libre-java memory lane

LWN published their index of all guest articles.
Since I was asked a couple of times to write about our libre-java efforts there are a couple of mine included:

It is fun to see how far we have come over the years.