Data in Motion

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== GCJ, Native Java Compilation, and Fully Open-Source Java ======

Recently, I have been thinking about the advantages of having native compilation of Java code using GCJ.

   - Application distribution of native binaries is much easier than worrying about what version of what JVM in how many copies is installed on the target computer. Yet, this could retain Java's "write once run anywhere" capabilities.
   - The Java open-source community could draw on a larger potential base of co-developers because GNU/Linux developers who insist on a completely free-software/open source software stack would feel free to embrace Java.
   - Open-source as a whole would benefit from merging the Unixish "free software" camp and the Java open source camp. More people working together will mean more synergy.
   - From the perspective of GNU/Linux developers, there are some nice advantages to be gained from integrating Hibernate and Tomcat and Eclipse into a Gnu/Linux system (to name just three wildly successful open source/free software projects that run on Java).

===== How can we do this? =====

The most notable missing piece in GCJ is an open-source rich client (desktop GUI) toolkit. It is necessary to have this to complete GCJ.

Ideally, there should also be a fully open-source Java IDE.  The open-source Java IDE must be made to use the open-source Java stack.  At a minimum, open-source Java should be supported by Gnome and KDE.

Where are we on each of these points?

   - SWT provides the last missing ingredient to make GCJ practical.
   - Eclipse is a high-quality fully open-source Java IDE that uses SWT.
   - It is currently very difficult to build SWT with GCJ. By extension, it is also very difficult to build Eclipse with GCJ.  Further, Eclipse has no support for building native Java applications      using GCJ as a builder. Further, Eclipse has no support for cross-compilation using GCJ and SWT.
   - I'm not close enough to Gnome or KDE to comment in much detail here, but it seems that Gnome applications are still mostly written in C or C++. KDE's dependency on QT is problematic, given the incompatibility between the GPL and the CPL/EPL. In either case, it needs to be possible for SWT applications to be built so that they can integrate nicely with GNOME or KDE if present and to degrade gracefully to a neutral behavior if neither GNOME nor KDE are present.

How can we move closer to this goal?

1) Create a SWT/GCJ project (within Eclipse.org or externally).  The lynchpin to having a fully open-source Java stack for desktop applications is SWT. Several people have created GCJ-hosted      applications with SWT, but they have mostly duplicated their efforts in compiling SWT using GCJ. Further, each new version of SWT seems to break native compilation in some way.

Having a SWT/GCJ project to centralize and coordinate building SWT using GCJ would:

   * Reduce duplicate efforts in getting SWT compiled with GCJ.
   * Provide a standard place to get SWT compiled with GCJ (or at least to get build scripts so that one can compile it oneself).
   * Enable the community to more rapidly provide the SWT team with feedback when the SWT team does something that breaks native compilation.
   * Create more visibility for both SWT and GCJ as an open-source solution.
   * Increase the size of the community around SWT and GCJ, which will help both to mature faster on all platforms.

Ideally, a set of build servers should automatically download each SWT integration build, compile SWT natively on all platforms, and flag any errors that occur. SWT buildability needs to be fail-fast when something breaks, not fail-when-some-programmer-needs-to-upgrade, as things are right now.

2) Create a project to fully integrate Eclipse and GCJ (within Eclipse.org or externally)

Hosting Eclipse using GCJ is only the first step. Additional steps include:

   * Integrating GCJ into Eclipse as a builder
   * Integrating GDB into Eclipse's debug perspective
   * Integrating the GCJ cross-compiler into Eclipse so that one instance of Eclipse can create binaries for any platform that can host a GCJ application.
   * Creating a cross-compilation project build system so that a developer can flag any of the possible cross-compilation target systems and have a binary for each platform a few minutes later.          
   * Making sure that all of these build systems are scriptable.
   * Developing a Java and Eclipse-integrated program installer. It should be possible for the Eclipse build system to create a setup program for any of the platforms on which the SWT application is cross-compiled.

===== Conclusion =====

We are at an exciting juncture in the life of Java and GNU/Linux; there are many opportunities to continue growing the communities that we already have and to strengthen each other.

Creating the bits of infrastructure described above will enable Java programmers to more easily create and distribute cross-platform native applications using their favorite programming language. It will strengthen the Java open-source/free software communities by making Java appealing to a wider array of individuals. It will give the GNU/Linux crowd access to the rich array of open-source Java projects including Hibernate, Tomcat, Eclipse, Prevayler, and many
others. This ultimately will strengthen both communities, and will greatly strengthen Free Software and Open Source.

~~LINKBACK~~
~~DISCUSSION:closed~~
Data in Motion

User Tools

Site Tools

Page Tools
