Slashdot Mirror
IcedTea's OpenJDK Passes Java Test Compatibility Kit
emyar writes "At JavaOne in May, 2006, Sun Microsystems announced they were going to release Java as free software under the terms of the GPL. The size of the task (6.5 million lines of code) was only eclipsed by the size of the opportunity for Java as a free and open technology. [...] This week the IcedTea Project reached an important milestone — The latest OpenJDK binary included in Fedora 9 (x86 and x86_64) passes the rigorous Java Test Compatibility Kit (TCK). This means that it provides all the required Java APIs and behaves like any other Java SE 6 implementation — in keeping with the portability goal of the Java platform."
If Mono wants to ever become suitable for enterprise use, it will need a testsuite and compatibility kit like this. One of the main benefits of Java is the stringent standards that implementations must adhere to. This brings a level of predictability that we just can't get from .NET or Mono. And for huge enterprise apps, that predictability is totally necessary.
They are using the "real" Java source. Only 4% of the Sun Java code wasn't released. So IcedTea only had to implement the 4% of Java that wasn't GPLed.
General, you are listening to a machine! Do the world a favor and don't act like one.
Actually, Sun's own codebase and a 4-5% of rewritten code passes Sun's compatibility suite.
TFA is about that 4-5% which was encumbered by patents (? the article doesn't go into details) and has been rewritten to make all the JDK free. That should be enough to finally get Debian include Java in their distributions.
If after more than a decade, there is not a single, independent, compliant Java implementation, then there is evidently something wrong with the Java platform. What in the world are you talking about?
There has been multiple compliant java-implementations for years now.
IBM's JDK (which is their own codebase).
and ORACLE's JDK (BEA JRockit)
both of which passed the Java TCK and can claim Java compatibility and compliance.
As for performance, the OPENJDK is based primarily on SUN's JVM code, hence it has the exact same optimizations (same HOTSPOT, and etc). Only a small majority of the code was replaced with open source alternatives which doesn't affect performance.
OpenJDK came to surface due to pressure of the OS community, to be to fulfill OS purists' ideals. For example, being able to embed the JDK into OS Linux systems.
OpenJDK is an effort backed up by Sun also, so that is no impasse here.
This is great news! I can see faster and greater improvements coming to the JDK having it open.
> I wish that someone would create a non-bloat version of the Java class libraries. Do an analysis
> of important use cases, redesigned the class libraries to be much less "fluffy"
Somebody did just this already.
Votez ecolo : Chiez dans l'urne !
Java the language and Java the platform are not at all the same thing. OpenJDK refers to an implementation of the platform, which includes the tools, the API, and the VM.
It's mostly written in Java (the language), by the way.
By the by, reading that first link made my brain hurt. When is GNU going to learn that the language of doom ("shackled," "trap," etc.) is a good way to ensure that you preach only to the choir?
Because each generation of "software guy" becomes n+1 generations removed from being a hardware guy himself. That is to say, the tools become "better" to make programming "easier" for people who aren't also electrical engineers.
At least, if I had to guess, that's what I'd say.
You forgot the corrolary to Moore's Law, Which is Gates's Law: Every 18 months, the speed of software halves.
If the code you posted is the best obfuscated Java code you can come up with, then I'm impressed. I've seen MUCH worse Perl, C, and even Python. Your code was at least understandable (albeit unnecessarily obtuse), thus demonstrating the unexpected readability advantages of the Java language.
P.S. Import statements are your friend.
Javascript + Nintendo DSi = DSiCade
Although 4% doesn't sound like much, it's actually just short of 8 billion lines. It sounds unbelievable that they could accomplish that so quickly, but Java's strength is in making it easy to write large amounts of code.
Badass Resumes
And as examples of bloat, you had to pick Swing, NIO and logging?!?
:-(
Logging is a quasi-identical to Apache's log4j, indeed this caused bad feelings among log4j's authors who felt Sun should just have officialized their API. Of course the reason Sun used it as an (ahem) inspiration is that it's very good, as demonstrated by the absolutely huge number of projects using it. And you know as well as I do that rolling out your own is a common developer trait, *especially* for trivial things like that.
NIO is brilliant. If it's too complex or low-level for you, just use the "old IO", which is *also* good - just not as low-level.
Swing, I can understand your feeling. Although the real problem with Swing is not "bloat" as in unnecessary complex and featurefull, it's that even though it only shipped in a JDK with 1.2 (which had the Collection framework), Sun bowed to short-sighted morons who kicked a fuss when it was suggested that it be put in java.swing (instead of javax.swing), and as a result still uses the old Vector and so on.
Generally speaking, what you call "bloat" is due to:
- the presence of libraries *you* don't use. Guess what, other people do.
- the provision for extensions. For instance, the java.net package is chock full of factories, abstract classes and interfaces that you seem to disdain. And indeed to 98% of developers who just use it for the net, that's all pretty pointless. The upshot is that should you require Unix or X25 sockets, you can still use the same API - I've seen it done. Sure you have to write the C code, but the Java code is all the same except the bit that gets the address. How many open-source language don't even have a common low-level DB API, forcing you to write you own single use abstraction layer when you need to target several DBs? At least with Java you know it's JDBC. Always.
Sun's attitude towards libraries has always been, as far as Java is concerned at least, make the simple easy, make the difficult possible. To me that's good design. Of course it means that easy can be more complex than with more specific APIs. But those tend to not allow the difficult at all
The One True Language, beloved by all (Objective-C) also uses 2 GiB of RAM for "Hello World", but just because it needs to use that memory to cure cancer and feed starving children.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
This is not completely correct. In the OpenJDK project we have been removing the encumbered code and have whittled down the nonfree part of OpenJDK's source tree to 0%. OpenJDK6's source tree is 100% open source. IcedTea has been matching this by removing some of the patches they applied. Most of what's left in IcedTea is a build system. Oh, and a plugin.