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

Mono needs a similar testsuite.

[by Anonymous Coward]

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.

Maybe you don't understand .Net?

[encoderer (1060616)]

For the last 2 years I've been doing Python work with a little PHP but the 2 before that were spent almost exclusively in .Net (C# and IronPython).

Right now on my dev box I have 4 versions of .Net.

They run side-by-side without issue.

There is no forced upgrade. It's like saying that C wasn't predictable because C++ emerged.

Apple

[thomas.galvin (551471)]

Sweet. Maybe was can start getting Java VMs on the Mac less than a decade after they're released now.

Re:Perfomance

[JimDaGeek (983925)]

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.

Re:Perfomance

[Reverend528 (585549)]

IcedTea only had to implement the 4% of Java that wasn't GPLed.

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.

Re:Perfomance

[by Anonymous Coward]

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.

Re:bfd

[PinkPanther (42194)]

How does having an "independent" (whatever that means) implementation make a platform "right" (or rather, lack of one make it "wrong").

What is it that is "wrong" in the platform? The fact that the base implementation is solid enough that few others found need to rewrite that wheel?

Re:bfd

[Jah-Wren Ryel (80510)]

What is it that is "wrong" in the platform? The fact that the base implementation is solid enough that few others found need to rewrite that wheel?

Because you get people coding to the bugs of the implementation without even realizing it, since it works after all. And then eventually you reach a point where new versions don't fix the bugs because too many systems depend on them. Sound like a monopolist you know?

Re:bfd

[AKAImBatman (238306)]

http://en.wikipedia.org/wiki/List_of_JVMs [wikipedia.org]

Re:bfd

[PinkPanther (42194)]

Or maybe its that the default implementation is really quite good.

Which it is.

Could it be improved? Sure it could...name a single software product that couldn't be. But there are many billions of dollars of IT projects that depend on Java, so trying to pass it off as immature, incomplete, incorrect or insufficient is nonsense.

Re:bfd

[pmontra (738736)]

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.

Re:bfd

[by Anonymous Coward]

So, Sun's own codebase passes their own compatibility suite. BFD.

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.

Re:bfd

[DickBreath (207180)]

Question: How long did it take Wine to come up with something mostly compatible with Windows? Fifteen years?

Have you considered that Java is almost like writing an OS? A runtime byte code, compiled form multiple source languages. Almost every service of an OS provided in a portable way. (eg, sound, video, graphics, multiple portable widget toolkits, network access, file access, system tray access, and the list goes on...)

GNU Classpath is mostly compatible now. Much like Wine.

Re:Really ?

[PinkPanther (42194)]

Does this mean it consumes 2 GB of RAM to display "Hello World"???

Man! Was that joke ever funning circa 1997...

Re:Really ?

[ais523 (1172701)]

Does this mean it consumes 2 GB of RAM to display "Hello World"???

Man! Was that joke ever funning circa 1997...

Yes, nowadays everyone has the 2GB of RAM, due to Windows Vista, so it isn't a problem.

Re:Really ?

[bsDaemon (87307)]

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.

Re:Really ?

[Reverend528 (585549)]

But linux runs on more hardware than OS X or windows. And it runs faster than both.

Maybe it has more to do with the skill of the developers than anything else.

Re:Really ?

[by Anonymous Coward]

You forgot the corrolary to Moore's Law, Which is Gates's Law: Every 18 months, the speed of software halves.

Re:Really ?

[Jesus_666 (702802)]

Does this mean it consumes 2 GB of RAM to display "Hello World" ???

So does C(++) because of all the memory leaks, every BASIC dialect because of interpreter overhead, Dotnet/Mono because it includes half of Windows, Python and Ruby because of all the objects, Lisp to store all the braces and Perl just because it can. PHP doesn't because nobody has tried it yet. ASM also doesn't because it always drops the processor back to 8080 emulation mode and can't address 2 GiB of RAM.

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.

Re:Just use a glove

[sidnelson13 (1309391)]

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.

Re:Language Compatibility vs. Class Libraries

[jalet (36114)]

> 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 [python.org] already.

Re:Language Compatibility vs. Class Libraries

[CastrTroy (595695)]

I'm not sure how much more performance you could achieve simply by culling the unused stuff. Java already dynamically loads only the classes you use into memory. We have gotten to a point where people don't want to rewrite their own XML parsers, sorting algorithms, cryptography libraries, UI components, network connection handling functions, and all the other wonderful stuff provided by the .net and Java APIs. We're probably a lot better off because of it. Less time wasted writing code that someone has already written a million times. If you still want a smaller version of the JDK, there's always the Java Micro Edition Platform [sun.com].

Re:Language Compatibility vs. Class Libraries

[by Anonymous Coward]

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 :-(

Re:Language Compatibility vs. Class Libraries

[AKAImBatman (238306)]

Source source = new StreamSource(new File(xmlFileName));
Result result = new StreamResult(new File(xsltFileName));
 
TransformerFactory.newTransformer().transform(source, result);

Was that really so hard?

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.

Re:Ask Slashdot

[The End Of Days (1243248)]

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?