Home

May 2008

S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031
Powered by LiveJournal.com

A software tsunami

A large underwater earthquake ends up creating an effect called a tsunami. The event can be detected by sensors around the world, but the resulting tsunami isn't immediately visible; if you're in the surrounding ocean you'll notice it, but it's only when it hits land that you really notice the effect.


On May 8, 2007, there was an effect a lot like an underwater earthquake in the software world. What are we talking about? The complete release of OpenJDK, of course. Since that time, we've mostly been in the underwater propagation stage. A lot has been happening behind the scenes such as removing proprietary bits, fixing OS integration, etc. But now, I think we're close to moving into the stage where the ocean recedes, so you can see the first visible effects.


The original OpenJDK release was a snapshot of the in-development version 7, so it was not quite suitable as a drop-in replacement for software that was targeting JDK 6. But recently in February, Sun released the sources to the stable version of the JDK, version 6. Thanks to the combined work of the OpenJDK team and the IcedTea project, this is now suitable to effectively work as a drop-in replacement for the earlier proprietary JDK releases.


On Fedora 8, this command worked for me:


sudo yum --enablerepo=development install java-1.6.0-openjdk

It pulled in new versions of a few things like zlib, but no big deal. In any case I think you'll likely see OpenJDK 6 pushed as an update for Fedora 8 too.


Why is this so important?


It's pretty hard to underestimate the transformative impact Java and the JVM have had on the software industry in the last decade or so. Now, Java is a very well designed language, but what I think is equally (if not more) important is the JVM. The JVM was really pretty far ahead of its time; the optimizing JIT compiler, the class structure, the threading model, concurrent generational garbage collection, etc.


There has been quite a lot of innovation on top of that platform. Ok, that sounds a bit buzzword-y. How about this: People have written a lot of awesome software for the JVM.


The examples seem endless; but let's mention some:



Impact ahead


But before OpenJDK, most of these projects effectively did not exist to the core of Free Software community. Even though all of these projects are themselves Free Software, to run it you had to download and install proprietary JDK. I think for most of us, we might as well have been required to download a Windows or OS X VM. At least that's the way I felt. It wasn't very integrated with the operating system. But most importantly, it was a blob which we didn't ultimately control, and we were right to avoid the Java Trap.


But, those were pre-earthquake times. The integration of the formerly-separate Java/JVM world with the Free Software community is ramping up very quickly. For example, Fedora is close to landing all of the dependencies of JRuby. I don't think anyone has started on things like Processing or World Wind yet - it could be you!


A shared Free Software runtime


I want to talk specifically about efforts like JRuby, and the newly-invigorated Jython. In an earlier blog entry, we looked at the fragmentation in the Free Software community. Every free language has its own runtime and libraries; and until now, building on the JVM wasn't an option if you wanted many contributors from the Free Software world. OpenJDK is finally changing that. Now, you can write a library using Java, it can be sensibly integrated with Free operating systems like Fedora, and can be consumed by anything on the JVM, which includes Python and Ruby, as well as new languages like Groovy. We'd actually be sharing more than just the OS kernel and C library.


Crucially, this is a platform we now control, because it's Free Software. And the original upstream is not just giving some standards or source code drops, they are actively helping us. In fact, "they" are "us" now!


Part 2 of this entry

Comments

(Anonymous)

Scala

Hi Colin,

It will certainly be interesting to see if the JVM will get more traction in the Free Software community now that OpenJDK6 is available.

You mentioned a bunch of interesting languages that can be used in the JVM. Scala is missing, however, so I was curious if you had looked into it. In my opinion, it's one of the most interesting ones.

Ismael

Re: Scala

I have a post about all the JVM languages queued up...had to cut this one short to post before dinner =)
But yeah, I briefly looked at Scala, and it looks neat.

Well designed?

Java's got its good bits, but I've always found that things like the total inability to make user-defined types behave like builtins, the OOP-violating hacks that make synchronisation work and the lack of closures rather outweigh its advantages - especially since C# appeared, which is also not perfect but ticks more boxes for me (a shame I have to use Java all the time at work).

That said, it's nice to have an open Java SDK and runtime. I don't really care if half my desktop is written using java-gnome or gtk# as long as it works! What language something's written in only really becomes important when it's broken and you have to go and fix it.

Re: Well designed?

Are those properties of the language, though, or of the JVM?

Re: Well designed?

Oh, the language. I'm sure if you're using something like Scala or Groovy it's better, I've just not really looked into them (although if either of them are like Boo... whee!)

(Anonymous)

Hibernate

There is nothing good in Hibernate, all it does is offers a solution to a problem that does not exist and more complexity to fuck you up. The newest Java standards are offering similar features on their own, and to use them you don't require one single line of XML.

Even if you want to use hibernate for some weird reason (perhaps because you are stuck to older Java platforms? or perhaps just retarded? the pointy haired boss insists?) it is really pretty mediocre as ORM if you compare it with some competition. For instance ActiveRecord runs circles around it in convenience and features - it is AGILE. Hibernate is pretty much as convenient as eating smashed glass and tin cans as breakfast, and it is pretty much as agile as a hippo dropped in a pool of super glue.

Re: Hibernate

Your post almost made me spew my breakfast cereal. Pretty funny. Right, I've used Hibernate indirectly through the EJB3 annotations, which works well - no XML required.

I haven't tried ActiveRecord, or really much Ruby at all; but it's pretty high on my list of things.

(Anonymous)

Re: Hibernate

"The newest Java standards are offering similar features on their own, and to use them you don't require one single line of XML."

No.

The newest standards define a persistence API that can be used in a portable way. Hibernate is now an implementation of this API (as well as Toplink and OpenJPA). JPA design is very strongly based on these implementations that existed before the stardard. For example JPA annotations that you mentioned existed on Hibernate before JPA was created.

And good luck trying to use ActiveRecord with a legacy database schema.

(Anonymous)

Re: Hibernate

Actually, you can use ActiveRecord very well with legacy database schemas. For the initial import you have to do couple tiny adjustments but there are ready tools for that and it is not much work even.

(Anonymous)

Some other useful Java projects...

Colin,
A couple of more java projects that are extremely useful and might benefit from being able to be easily used now that java can become ubiquitous.

  • Sphinx-4 (http://cmusphinx.sourceforge.net/sphinx4/): speech recognition

  • FreeTTS (http://freetts.sourceforge.net/docs/index.php): speech synthesis

  • uDig (http://udig.refractions.net/): GIS and mapping

  • Multivalent (http://multivalent.sourceforge.net/index.html): PDF/HTML/TeX document manipulation tools

  • iText (http://www.lowagie.com/iText/): PDF generation (& some utilities)

  • JFreeChart (http://www.jfree.org/): chart/graph generation

  • OSGi (as a component module for sharing the same process space)

Future of Java on Fedora

Nice post.

Now what will happen with GCJ and all platform-dependent GCJ-compiled software in Fedora?

Re: Future of Java on Fedora

Almost certainly we (Fedora) will eventually stop AOT-compilation of programs with GCJ. We'll keep doing it for some period of time because GCJ is faster than the Hotspot interpreter on embedded/legacy architectures like ARM; but long term I don't think it makes sense to do for Fedora x86/x86_64.

What will happen with GCJ upstream is of course an important factor in this equation. They have the whole class library now, but I think a JIT is almost always better than AOT compilation.

(Anonymous)

thank you

favorited this one, guy