Tuesday, September 30, 2008

GCJ, MingW and GNU Classpath

GCJ is an open source compiler for Java, part of the GCC compiler set. Whats special about it is that it can also compile Java code into a native executable file which does not require a JRE to be installed to run. This method also speeds up the application. Look here for a complete explanation.

The last time I checked out GCJ was back in 2003. Last month I decided to look it up again as I have a small project that I wanted to develop in Java. Now the application is supposed to be a small utility which will inetract with a Project Management software via websrvices. One of the main requirements is that the utility should load up fast as 40% of the PCs it will be run on are running on Pentium 3. A regular Java app takes ages to load on Pentium 3. GCJ gave me some hope that I might be able to use Java for the app.

I downloaded the latest version of MingW, installed the required iconv binary and compiled a "Hello World" on System.out example. Worked perfect. I moved on to a "Hello World" using a simple Swing frame with label. It compiled successfully, but when I ran the exe file I got an error "AWT Toolkit not found". After a lot of research I found out that although the GCJ developers claim to have merged their code with that of GNU Classpath, since GCJ is part of GCC, they have stayed clear of all GUI code from the codebase. In short GCJ will not allow me to run Swing or AWT apps.

Next I tried to use the regular rt.jar file distributed with Sun JDK to compile the executable as GCJ has an option for choosing the base classes jar file path. The compiler started giving a "... zero-length 'gnu.gcj.gcj-compiled' attribute ..." error. I then understood how GCJ actually works. The GCJ developers have already compiled all their Java base classes into a native library. When creating the exe the compiler links this library to your exe. If I try to use a jar file like the one provided with the Sun JDK or if I recompile GNU Classpath and use it with GCJ, the compiler will first need to compile that jar file into a native library. Although this seems plausible, I really did not have time to try this out.

I also looked into using other Java GUI toolkits. First I went with Thinlet and lwvcl but then I realized that they are based on AWT and thus will not work. Then I looked into using SWT which is not based on AWT and I came across this page. Here you can download a complete MingW, GCJ and SWT environment that allows you to compile native executables with GUI support for Swing. It uses the SwingWT package which allows you to write Swing code to use SWT. The SwingWT package is not production ready though.

Another possibility is to write the app's GUI in pure SWT. I still have to run some more testing on this. I have successfully compiled a "Hello World" example but am still unable to execute it. I found very good and detailed directions here. Will probably try it again next week.

No comments: