Classpath v/s Sun: nefarious plans to partially open source Java to kill Classpath

Sun is up to its old tricks again. Jonathan Schwartz has been devoting too much air time against GPL which normally means GPL has hit a nerve. In this case, the onslaught of open Java in the form of GCJ, libgcj, and Classpath are really hurting.

In past, Sun has resorted to tricks like opening up its sources to 'contaminate' those who read it inadvertantly. Now there is a last-ditch attempt to stop Classpath from reaching 100% API coverage because it would be very difficult to prove that a GNU developer hasn't taken a peek at the open Java sources on Sun's site.

Classpath meanwhile merrily moves along. As we can see from the nightly japi scans, the compatibility with 1.4 is reaching very high levels.

There is news of compatibility with 1.5 reaching 66% or so which is a great achievement for an open source project that is tagging along at its normal pace. In any case, I don't think 5.0 has taken hold yet. IBM hasn't even released it so far.

All in all, its worth taking another look at Classpath. If you haven't been contaminated by having seen Sun's sources, you should seriously consider joining the crusade to deliver free open Java APIs.

Most of the missing APIs in 1.4 case fall under a few categories - sound and CORBA being the primary ones. There are other miscelleaneous ones like javax.security.auth.kerberos, javax.imageio.plugins.jpegio, javax.swing.plaf.* , etc. Apparently , Red Hat has been helping port AWT and Swing stuff.

So what is really misssing is someone good in sounds, jpegio, kerberos and OMG CORBA stuff to lend a hand. It's time some corporate entity helped out because creating a complete set of APIs before Sun manages to contaminate the world is a good move for the industry.

The biggest pieces missing from 1.5 are javax.management and javax.lang.management. I don't know if classpathx project had those.
Sound has been missing since 1.3 and CORBA and Swing since 1.2. It's obvious not many people use these packages, at least not in the the open source community. If they did, they'd simply write them. That's the wonder of open source. However, Java which is still controlled by Sun, has rules that APIs need to be complete before they can be called Java.

Of course there is the larger question as to whether the open source community really cares about the APIs being complete or officially marked Java. Look at JBoss. The open source J2EE app-server became popular before getting certified J2EE compliant. There are a host of users of Classpath who don't really care about it not being fully Java compliant:

• Jikes RVM from IBM
• Intel's Open Runtime Platform
• SableVM
• Jaos (Java on Active Object System)
• FLEX Compiler
  

There are a host of open source JVMs that work well with Classpath. There is effort underway to merge GNU gcj's libgcj with GNU Classpath and it's going great!

So get off your horse and start contributing to GNU Classpath and help bridge the gap with Sun APIs.

Jikes compiler in sourceforge.net

IBM recently moved the Jikes compiler to sourceforge.net. As I have told elsewhere on this blog, Jikes is the name used for both the Java compiler (that converts a Java source file to a bytecodes class file - like javac) and the RVM (research VM). The compiler has reached sourceforge but not the RVM so far as I could see.

This brings up an interesting point about IBM's public license. This license doesn't indemnify anyone who uses the sources and it is the responsibility of the user to ensure they have the right set of permissions. In fact, even if IBM held some patents on this technology, they could eventually sue the user for not having signed a technology deal with IBM. Sounds suspiciously like a Sun in the open source wool.

The availability of an open source Java compiler is a good news though. Among other things, it can be used by Eclipse for the class file generation. This could also be used by app-servers to generated classfiles from dynamically generated JSPs and Servlets. Both app-servers and Eclipse would thus, only requier a JRE on the system and no longer need the entire JDK.

Does that mean the Jikes compiler is a pre-cursor for Eclipse to start bundling it?

Open Source JVM from IBM

My earlier post was inspired by rumors in the industry of an impending IBM open source JDK. I looked at Jikes to see how viable that option is as an open source JVM. Jikes is released under CPL, one of the myriad open source licenses controlled by OSDL. It is also considered free software by Debian.

According to Appendix B in the user guide for Jikes (http://www-124.ibm.com/developerworks/oss/jikesrvm/userguide/HTML/licenses.html), someone in the team is working to create a Debian package with pre-built Jikes including the GNU classpath libraries.

Given the fact that IBM is behind Eclipse in such a big way, it is surprising that there is no JRE distributed with Eclipse today. One of the likely reasons is that Jikes performance is probably not up to par with commercial offerings like BEA JRockit, Sun hotspot, and the IBM JVM. By allowing users to install their favorite JVM, Eclipse keeps them free from the performance issues. But if it starts to come pre-bundled with Jikes, even if as an extra option, this would help the spread of this open source JVM much more, and bring more volunteers as part of a community around it.

Given that Jikes is pure-Java, it requires another JVM to start. I wonder if we can combine gcj and Jikes to create native executable out of Jikes and use that with Eclipse.

Jikes RVM from IBM

Jikes is a research VM for Java from IBM. You can find info about it at IBM's Jikes site. It runs on IA-32 and PowerPC based platforms and so far as I know, is not currently available on Intel's Itanium Linux platforms. It may be lower priority for Intel to port it to Itanium given their investment in BEA to ensure JRockit is available on Itanium Linux.

An interesting thing about this JVM is that it is written entirely in Java, thus making it easier to retarget it. It is self-hosted so it doesn't need another JVM to run itself. Also, it appears to have most major functionality and performance features required for a useful JVM like thread and synchronization support, garbage collectors etc.

Jikes is based entirely on GNU classpath. Also, one of the success criteria for open source JVMs is to be able to support the open source Java development platform - Eclipse. Jikes does most of that (SableVM claims to be able to fully support Eclipse).

If the rumors of IBM's open source JDK ever come true, it would likely be with Jikes and classpath (though IBM does have resources to do a full API implementation).

Have you had any experience using Jikes? Do drop me a note and tell me how it went!

Open Source Java

One of the biggest movements of yesteryears - Java - is not yet available in the open source arena. It is one of the few closed down languages, which is funny because Scott McNealy actually used to point out that Microsoft could control the language you speak in the world. Bill Gates got one up on him by pushing C# into ECMA, while Scott simply played around with ECMA until the last day when Sun's lawyers showed up with copyright documents, after Java had gained world wide acceptance.

The last serious effort to develop a JVM - blackdown - was stifled once Sun bought the company (or had some sort of commercial arrangement with them, I don't remember which). You are, since then, dependent on either Sun's own low performing JDK, BEA's JRockit, or IBM's here-today-gone-tomorrow JDK. Sun has no real commitment to Linux, BEA has an app-server which is the primary focus of the JVM, and that leaves IBM to help out with Linux. They have a few open alternatives like their Kaffe JVM.

But the JVM is only part of the story. You need the APIs to make it all work, and today, even BEA uses Sun's JDK along with its JVM. GNU has an effort called classpath, but it is hindered by the fact that the APIs are not complete. There are open source JVMs like the SableVM around, but they are weak - Sable for example is just an interpreter.

There has been wide speculation whether Sun would free up Java. Scott & Co haven't yet figured out how to make money off the language, and it is a money sink for them. Jonathan Schwartz tends to tantalize the world by suggesting that JES is next to follow that crafty CDDL lincense now that solaris10 has been offered under it. While all this is going on, there are very strong rumors that IBM will be releasing an open source JDK soon. That could have the electric effect of jumpstarting Java, especially if Apache or a similar organization creates a parallel entity to JCP to update APIs and modules, and helps grow the ecosystem. Someone might as well create a variant of C++ that you can use to convert back and forth from Java, (maybe Bill Gates should donate the code that converts to C++ to the open source community and win accolades like IBM and Sun are doing through their patent donations).

This is a very necessary milestone in the future of Java. Sun has kept the JDKs free because they would lose support from other vendors as soon as they charge for it. But there is the possibility of them asking for royalties sometime in the future, especially if it becomes technically bankrupt like SCO. Given the last scare Linux had, it would be difficult for enterprises to justify using Java because it can come back to haunt them, especially if their mission critical software runs Java.

I am looking forward to IBM's open source JDK and want to see the reaction of Sun's lawyers (sometimes I think their law team is stronger than their hardware team!!). That would tell us a lot as to whether an open source stack is feasible!

GCJ: Ahead of time compiler for Java

I have never had an opportunity to try GCJ from GNU. I have been looking lately at open source implementations of Java, and came across this interesting product. It is described in detail in the Linux Journal. The fundamental premise is that Java is very similar to C and C++, Reflection, dynamic proxies and similar features aside. It is possible to do ahead of time compilation (as against just in time compilation) for Java programs.

There are several advantages to such an approach. Performance is one, especially against JITs which have high warmup time. Even though most JVMs now sport a combination of Interpreter and Compiler, there are commercial JVMs like BEA JRockit which still do not have an interpreter. GCJ with static executables would perform better than these. For server side applications though, the dynamic profiling available to lazy compilers allows them to perform better.

Another major advantage of gcj is better linkage with C/C++ code. This shows up as a useful feature when we debug Java programs using standard debuggers like gdb.

Of course going to static code violates the write-once-run-anywhere philosophy of Java. In particular, this would affect browser downloaded applets. Either we'd have to ensure that gcj is installed on the systems that download the class files, or we'd have to set up native executables for the browser platform, going against one of the biggest advantages of Java.

But this may not be as big a hindrance as it may appear. Java has steadily moved to the back-end as more of a C/C++ replacement due to programmer friendly features like automatic memory management. In these cases, it may be perfectly acceptable to create a static executable from the Java classes, especially if that leads to better performance.

Gcj is available today for IA-32 and PowerPC based platforms. I don't know of any plans to do an Itanium version, which is the other Linux platform.