![]() |
![]() |
|||||||||||||||
|
||||||||||||||||
|
![]() |
GNU Java is evil
If you are lucky enough to have found this blog entry and unlucky enough to have some form of GNU "Java" (GCJ) installed on your system here are two important steps to help you out.
So now to the why. GNU "Java" is the worst software project ever foisted on the public. The fact that it's open source and free doesn't mitigate that, and frankly just reflects badly on the open source community in general and GNU specifically. Which is a real shame because by and large open source (and GNU specifically) are really very good things. But GCJ is just such a disaster. Here are a few of the things that make GNU Java bad. Missing Core Libraries GNU Java is missing support for among other things AWT and Swing although these are apparently in development. The GCJ site among other things essentially claims that there are too many APIs in Java etc. Fair enough I suppose but no AWT support? This is 2009. The "final" version of AWT was released with JDK 1.1 in February of 1997. Twelve years is more than a little behind. What core libraries are supported are mostly broken and incorrect and sometimes scarily so Fundamentally basic parts of the Java API are not implemented properly in GCJ when they are implemented. For example threading doesn't work "quite right" in GCJ. And neither does support for Sockets. Both of which I have personally experienced. Even the GCJ site makes comments that programs will run better by disabling threading support for non-threading programs. A comment that is disturbing enough on it's own but gets worse when you stop to think about it, what kind of GC (garbage collection) support is there exactly? The truly frightening stuff though are the broken ways in which other APIs are implemented. Like for example the reflection API which is noted by the GCJ site for having some security related problems (aka calls that should throw permission denied don't). Things that break a security model as a minor aside should be treated with at least a great deal of suspicion. It's all pretty useless anyway Since you can get working Java from Sun for Windows, Solaris and Linux. Apple provides it's own working versions. And IBM has working versions for several platforms including Linux and AIX. It makes one wonder what the point of GCJ actually is. BSD I suppose. But it's hard to conclude there is any real demand on a system not supported by a major vendor when a 12 year old project as this one is still in such poor shape. The weasel wording used by the GCJ site to describe itself Really the thing that makes GCJ progress from simply a bad project to an evil one is the whining, doublespeak and general weasel wording used on the GCJ site. To begin with they neglect to mention that GCJ is not compatible with "real" Java. For example Serialization and RMI don't work from GCI programs to real Java programs. I suspect because these sorts of comments would lead a person to conclude that GCJ is incompatible junk. Which of course it is. But it's worse than that. As commented above there is a good deal of whining about how difficult it is to implement a changing API such as the whining done here "I think it's important to stress that there is a big difference between Java and the many libraries which Java supports. Unfortunately, Sun's promise of "write once, run everywhere" assumes much more than a JVM: you also need the full set of JDK libraries. Considering that new Java APIs come out every week, it's going to be impossible to track everything. " That comment sounds reasonable until you realize it's addressing the lack of AWT support! This isn't a new API, it's been around for 12 years now. So really the best thing you can say about that comment is that it's disingenuous. And the same amount of spin applies to the versioning, aka what version of Java does GCJ actually support? Well on the front page of the GCJ site it says
"supports most of the 1.4 libraries plus some 1.5 additions"So 1.4 and 1.5 are mentioned. (It's worth pointing out that Java is now on version 6, 1.5 has entered its EOL phase and 1.4 is officially unsupported so to begin with 1.4 and 1.5 are not exactly accomplishments to be proud of). However the statement is most of the 1.4 libraries which really means that at best what is supported is 1.3. So by their own admission GCJ is at the level of a Java version that was superseded in February of 2002, seven years behind! But of course that impression is just so much hopefulness because it isn't even at that level. For one thing as noted no AWT support means that it isn't really at JDK 1.1 yet. Okay, okay, it if was just all the GUI stuff we might be able to let that go (although it's pretty damning). At least the rest of the stuff works right? Well not exactly. The GNU Classpath project (a fundamental part of the GCI system) has this to say
"GNU Classpath 1.0 will be fully compatible with the 1.1 and 1.2 API specifications" Which is another way of saying that it doesn't support Java 1.1 yet, never minding the GUI components. All in all it's difficult to understand why GCJ hasn't been mothballed and it's impossible to understand why several Linux distributors continue to include it as part of their distribution. If you are inexperienced with Java and come to know it only through GCJ your experience would be pretty poor and worse the GCJ site is not honest about the shoddy state it's in and attempts to rubbish Sun to explain its own deficiencies. A truly terrible product and a site bordering on telling outright lies make GCJ not just a useless or bad project but truly an evil one. *******************A previous discussion of some of the things discussed here can be found here. An example of GCJ making a basic task impossible can be found here. The weasel worded GCJ website can be found with Google, I refuse on principle to link to it directly. Tags Categories Comments EJP - Feb 18th 2009 8:04 PM |
||||||||||||||
|
Home | About | Blog | Stuff | Contact | Privacy Policy | |||||||||||||||
| © 2008 Max Stocker | ||||||||||||||||