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.
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.
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