I’ve had a couple head-scratcher bugs from a couple of jUploadr users, and unfortunately, they all have the same cause.
The users were complaining about random crashes, and especially scary, the inability to save their preferences. After asking in vein what the trouble was, one of them sent me in a stack trace. From the trace, it was obvious what the problem was –she was using GIJ.

Since Java isn’t free software (free as in free speech, it costs nothing to download) most Linux distributions don’t include it by default. However, they’ve started including a free version of Java called GIJ/GCJ. GIJ/GCJ are front ends for GCC, the venerable C/C++ compiler and they’re fantastic projects, but GCJ/GIJ are not mature enough for distribution. There are huge swaths of the standard Java API that they don’t provide, including support for saving and loading application preferences. The end result is that when a user tries my application under this system, it just doesn’t work.

Java currently suffers from a reputation of sluggish performance, funny looking UIs and strange error messages, and GIJ just adds to these perceptions. It’s no small feat to write an application that runs unmodified on three separate operating systems unless you use Java. It’s sad that the free software umbrella –which brought you jUploadr, and all of the libraries that it uses– also makes that more difficult.

10 Responses to “Gnu’s Incompatible Java”

  1. yannoweb Says:

    (Oops) I noticed this page just after I posted on the last one about the GCJ error. Do you know how I can work around this problem? Otherwise I’ll just wait until you have the next version.

  2. scohen Says:

    Yes, go to http://java.sun.com/j2se/1.5.0/download.jsp, and download JDK 5.0 Update 5.

    Then (as root) move the .bin file to /usr/local and execute it. You might need to do a chmod u+x before you do so.

    After that,type
    ln -s /usr/local/java /usr/local/jdk1.5.0_05

    then cd to /usr/local/bin and type
    ln -s ../java/bin/* .

    Now you need to remove the old version of java (GCJ)
    rm /usr/bin/java

    That’s it.

  3. slux Says:

    So you would prefer no Java support at all for free software users? gcj/gij currently aims to support popular apps such as eclipse, azureus, ooo2’s java components and that is the reason it is included in the distros, it is useful at it’s current state even if it does not happen to run every possible java app. You could always modify JUploadr to be runnable on gij so you don’t force anyone to change to a non-free version of java just to upload some pics to flickr.

  4. scohen Says:

    No, I’d prefer to have gcj/gij fix its bugs.
    jUploadr works on Windows, Linux, MacOS and anything else that has the sun or IBM JVMs. That it doesn’t work on GCJ/GIJ just speaks to that project’s immaturity.

    The whole point of Java is that I shouldn’t have to change my software to work on another JVM. It’s up to the manufacturers of a given JVM to make sure they’re compatible and GCJ isn’t. Would C developers like it very much if some of the standard libraries on some OSes had functions that didn’t work? I don’t want to have a bunch of code in there that detects the JVM and doesn’t call a certain method if it’s running under GCJ. I’d rather be adding features rather than re-implementing the entire freaking preferences API.

    People running linux can always download the Sun, Blackdown or IBM JVMs, the only reason at all to use GCJ is an idealogical aversion to commercial software. Hell, Java doesn’t even cost anything.

    This might sound harsh, but my tone might have been different if you submitted a patch to get jUploadr running under GCJ but instead, it seems that I’m expected to ‘fix’ my app when the bugs are actually in GCJ. I’m working on this project all by myself, and don’t want to re-implement JVM functionality just to appease someone’s ideology. If you want to do that, that’s fine, but don’t expect me to do it for you.

    Furthermore, I’ve helped several people remove GCJ and install ‘real’ java, and you know what happens? Better performance, better consistency and all the bugs are fixed. Sounds like a real JVM makes linux better, not worse.

  5. slux Says:

    Not everyone can actually (with a reasonable amount of effort) run Sun’s JVM. Linux on the PowerPC, SPARC and a whole lot of other platforms do not have Sun JVM binaries available. Then there are operating systems such as BeOS/Haiku/Zeta, all the BSDs etc. that also have the problem.

    What’s more, it’s simply a legal issue, distros *cannot* ship Sun’s JVM without a legal agreement with Sun. Especially for the smaller community-based ones this is just impossible since there’s no financial backing or an organisation large enough for Sun to really be interested. A few larger ones prefer not to include it as well, both for practical and ideological reasons.

    My suggestion to work around this in JUploadr assumed you have desire to let your users have a good experience and make it possible for them in the first place to run the software at all. Few people are going to change to a Sun supported processor architecture/OS or change their values because of JUploadr. They’re simply not going to have running it as an option.

    GCJ will continue to get better and now that it’s been really gaining some momentum recently, being included in several major distros and all, I’m sure it will run JUploadr some day. It’s just not a priority for GNU Classpath developers, stuff like Eclipse, OpenOffice.org and so on is. I’m just saying it has it’s right to exist and a real-world use. It’s not feature complete or as fast but people can use it to run some apps and are doing that. Whatever’s available on a gcj-using distro’s packaging system will work while random apps downloaded from the net probably won’t but might.

  6. scohen Says:

    That’s fine and dandy, but jUploadr uses SWT, which is not available on several of the architectures you mention, so it’s really a moot point.

    What’s more, it’s simply a legal issue, distros *cannot* ship Sun’s JVM without a legal agreement with Sun.

    Understood, but I have to say, I really don’t care about this. I downloaded java, and I’m sure the average Linux user can do the same as well. Most linux users have a more pragmatic attitude about software than you seem to, this being the first call to get jUploadr to work in GCJ and all.

    My suggestion to work around this in JUploadr assumed you have desire to let your users have a good experience and make it possible for them in the first place to run the software at all.

    That’s really beyond the pale. My desire for my users to have a good experience dictates that I don’t want them to have random crashes caused by unimplemented features. You and I seem to differ on the definition of ‘good experience’. When I hear that phrase, I assume that it means ‘the program works well, looks good and makes the users happy’ you must think that means ‘runs entirely within the umbrella of free software’. I’m going to bet my users would agree with me. Also, if they’re not running my software, they are not, by definition, ‘my users’.

    GCJ will continue to get better and now that it’s been really gaining some momentum recently, being included in several major distros and all, I’m sure it will run JUploadr some day. It’s just not a priority for GNU Classpath developers, stuff like Eclipse, OpenOffice.org and so on is.

    That’s really great and all, and you need to understand that from my perspective, getting jUploadr to run under GCJ is at the same priority as organizing my sock drawer. I’m actually quite surprised that any of those programs run without the prefs API. Meanwhile, I’m still waiting for you or anyone else to contribute to the effort to get jUploadr to run under GCJ.

  7. scohen.org » Blog Archive » How not to ask for a feature Says:

    [...] I got a comment a week or so ago on an old post that immediately rubbed me the wrong way. The post was talking about an open source version of Java and its many flaws. In the post, I concluded that it was an admirable project, but wasn’t mature enough to distribute widely. The commenter immediately went for my jugular –here it is: So you would prefer no Java support at all for free software users? GCJ/GIJ currently aims to support popular apps such as eclipse, azureus, ooo2’s java components and that is the reason it is included in the distros, it is useful at it’s current state even if it does not happen to run every possible java app. You could always modify JUploadr to be runnable on gij so you don’t force anyone to change to a non-free version of java just to upload some pics to Flickr. [...]

  8. Khristian Says:

    I agree with scohen. After all, not even with eclipse does this weird GIJ work…
    I’d rather download Sun’s JVM than break my head trying to get the GIJ to work.

  9. scohen Says:

    With Java going open source in the next couple years, this is largely becoming a moot point.

  10. Michael Kimsal’s weblog » Java incompatibilities Says:

    [...] But my joy wasn’t to be.  I didn’t have the Sun Java - I had ‘gcj’ (http://gcc.gnu.org/java/).  It’s not the real thing.   Major Java apps - Eclipse and Limewire, to name just two - don’t work with the whole gcj system.  They require ‘real’ Java (from Sun or perhaps some other party I don’t know about).  From reading   various pages like this one, it’s pretty obvious I’m not the only one who notices that the gcj stuff that’s shipped with some Linux distros is bad.  It’d be better to not ship a JVM at all rather than ship one that doesn’t provide a good experience.  Dare I say, it’s ‘incompatible’ with standard Sun and IBM JVMs.  Didn’t Sun take Microsoft to court over this principle?  I may not remember my Java history too well, but it seems that Sun, concerned as they are about licensing and image and all that, would take more steps to either help the project along, or prevent them from making such an association with the Java name - it really provides a bad experience to anyone thinking they’re getting “Java” to end up with the setup that is the current GCJ. [...]

Leave a Reply