OSNews

Hi Raptor,

There are no automatisms involved here. Free software is not automatically superior to non-free alternatives on other aspects, but freedom. It takes work, usually lots of it. And it takes a good deal of motivation to go ahead with that work.

I believe that for any platform to be relevant enough to attract people to create a free software alternative, it needs to provide an incentive to do so. With Java, the incentive is finally here: it has become not just useable for building cute applets, but useful for building large scale applications from a vibrant ecosystem of free software. So now there is a growing interest, beside early adopters, to have a fully free platform for Java development and deployment. That interest didn't exist befor since Java was not that interesting for writing free software: it was just another proprietary platform like visual basic, delphi, and so on.

It was mostly due to the Apache Software Foundation's work on Jakarta that Java actually became useful for writing free software. Now many people are starting to get annoyed enough by the fact that you need to install non-free software to use free software that they are doing something about it. Some of them are asking Sun to do them a favor. Others have realized that freedom comes through their own deeds, and started to implement and improve free implementations of Java class libraries and runtimes instead of waiting for Sun to change their mind.

I've seen a lot of interest in GNU Classpath lately. Things are getting hot, like in the early Linux days. But it takes time, still, to come up with something as good as or better than the JDK. Just like it took a few years for gcc and g++ to become the 'industry standard'.

Judging by the time it took Linux, gcc and g++ to become really nice tools, I'd say 10 years is the usual time span it takes to establish a free software implementation. So with that calculation, I'd expect free software java implementations to become viable replacements for non-free alternatives for most tasks between 2006 and 2008, if we can attract more competent hackers. Come in and be the next Alan Cox

Note that I say "implementations", i.e. that I use the plural form. I don't believe in 'one size fits all'. GNU Classpath is in part so successful because it creates an ecosystem of java runtimes, that ocassioanally take Java where no Sun-derived code has been before. If you want to see some really innovative stuff, you could take a look at JikesRVM from IBM (high-performance JVM written in Java using GNU Classpath, of course), and IKVM (fast Java runtime for .net). There is a ton of exciting GNU Classpath based stuff going out there, so I don't doubt you'll be in the comfortable situation to pick and chose the most suitable runtime for your tasks in a few years. You may still prefer Sun's runtime, of course. But you'll be able to chose it for its own merits, instead of just because its the only thing that runs your code.

Compatibilty is a big issue that's coming up. Unfortunately, noone can say how compatible even Sun's runtimes are, without trusting Sun. The problem with trusting Sun is that they might have tested their runtimes on a handful of selected platforms, but as those platforms change underneath through security patches and bug-fixes, it's not certain that Sun's runtime still meets the specs. As noone can verify Sun's claims since their compatiblity test suite is not freely available, noone can say for sure.

Judging by http://java.sun.com/j2se/1.4.2/compatibility.html#binary Sun has released 1.4.2, Sun has released JDK versions in the past that didn't pass their own compatibility kit:

"In J2SE 1.4.2, there is a known JCK failure. When running with the -enablesystemassertions flag, in rare cases, converting a floating-point number to a string can throw an assertion error."

Running Sun's runtimes against the freely available, vendor independant Java API compliance test suite Mauve shows that Sun's implementations have compliance problems with the API specifications, (just like anyone else).

Sun has broken compatibility between releases in the past, for example by adding methods to JDBC interfaces, or changing the values of final fields. Unfortunately, Sun has apparently decided to take all the older information on binary compatibility changes between releases offline, so I can't point you to URLs anymore. I assume achive.org has them, or you could google for my discussions of Sun's notion of compatibility in other forums.

I don't say that the free runtimes don't have bugs. In my opinion all non-trivial software tends to suck, more or less. But at least with free software, we have the possibility to fix it, and to share our fixes.

For companies (and more so for governements), the question is of course about control of their core IT assets: do they control their data processing infrastructure themselves, or do they allow 'tainted cards' in their software solution stack? That's why I believe that we'll see more uptake of free java runtimes in the future: relying on a non-free JDK in your otherwise free enterprise software stack doesn't make a lot of sense in the long run.

GNU Classpath fixes that by making it easy to build java runtimes by providing the largest bit of work, the class libraries, to anyone who wants them. So you get a lot of potent runtimes, instead of a single solution. You'll get real choice, instead of various flavours of the same thing.