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

Re:Perfomance

[JimDaGeek]

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

[pmontra]

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

[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:Just use a glove

[sidnelson13]

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:Ask Slashdot

[The End Of Days]

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?

Re:Ask Slashdot

[Thiez]

Java comes with a huge library of classes. It seems that is was the article about. I'm sure you can write a working java interpreter in less than 6.3 million lines.

Re:Language Compatibility vs. Class Libraries

[Octorian]

But at least its only a mountain :-)

I don't know if Mono can ever catch up to the whole mountain range that .NET has bundled in. Especially since its taken far less seriously than Java by this community.

Re:What's the point?

[Vectronic]

From what i understand, the advantage is that distributions that are (or try to be) 100% "Open Source" can now add this to their list.

Ontop of that, it means that anyone and their dog can dig through it, and maybe even improve on it, plus being able to make better java applications knowing exactly whats going on...

Re:What's the point?

[sidnelson13]

Of course, we can search for enlightenment ourselves!

OpenJDK FAQ [sun.com]

Cheers!

Re:bfd

[AKAImBatman]

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

Re:Just use a glove

[VGPowerlord]

I was under the impression that OpenJDK [java.net] was the Sun JDK7 project.

Re:Language Compatibility vs. Class Libraries

[AKAImBatman]

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:What's the point?

[j79zlr]

64-bit plugin for 64-bit browsers. For some strange reason Sun refuses to release one. The current icedtea plugin for my Gentoo amd64 install works about 50% of the time. Hopefully they can get that up to where it is more compatible

Re:Really ?

[afidel]

Sure they could the Cray T90 came out in 1995 with up to 8GB of ram and the Y-MP M90 came out in 1992 and had up to 32GB of ram, the T3D came out in 1993 with up to 64GB of ram. Basically your run of the mill supercomputer had several times that much ram by the mid 90's =)

Maybe you don't understand .Net?

[encoderer]

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.

Re:Perfomance

[sm62704]

Yes, which would affect the size of the source without bloating the code. That's why I asked. If 5 megs of the 6.3 megs of source is comments, that's a GOOD thing. Little or no bloat and the code is decipherable.

Re:Mono needs a similar testsuite.

[Anonymous Coward]

Even if you discount Java's superior performance,

I'm pretty sure .NET has Java beat in several areas. For example, generics. In Java generics are just syntactic sugar for casting everything from java.lang.Object to something else. Each cast is a runtime type check, which comes at a performance penalty that I don't believe is trivial. .NET actually generates unique code without that casting.

superior APIs that are decades ahead of anything at microsoft,

APIs, maybe, I don't know, but language features, definitely not. I don't use C# really, but even as someone with only a passing familiarity with it I can name a few things about it that make it seem much more productive to work with than Java:

• Support for generics is "real" rather than an afterthought, mentioned above.
• Using C# delegates for closures is syntactically much nicer than anonymous classes in Java.
• Accessors in C# actually make syntactic sense, where in Java everybody writes ugly statements like foo.setBar(true) (and it gets more complex, verbose, and uglier than this example, too).
• C# has yield iterators, i.e. real iterators like in Python. Try writing an iterator in Java for a tree structure. You pretty much have to think about breaking it into a state machine. In a language that has real support for iterators it's as simple as writing your standard-issue traversal function.
• C# has type inference in declarations with an initializer, eg. var foo = new SomeVeryLongClassName() and foo ends up with the right type

These are just a few. I'm sure people who are more familiar with C# than I am can name more.

For the record, the kind of coding I do is much more geared towards lower level stuff, so I don't use C# or Java much at all. But I'm aware of the features of both, and I definitely would say hands down that between the two major high-level, VM languages, C# is the better one. It is definitely in the best interest of free software and open source to replicate some of its strong points over Java. Unfortunately Microsoft has a credibility gap, so a lot of people dismiss it without being aware of its features. Mono is an okay start, but still lacking...

Re:Perfomance

[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:Maybe you don't understand .Net?

[Anonymous Coward]

You may not have hit any issues this way but I have. There's one strange case I know of without a good solution. The .NET control container in IE will by default use the newest runtime installed on the machine when rendering a web page that contains an embedded .NET object (client side control). If the control was compiled against 1.1 and you have 1.1 and 2.0 on your machine it will try to run it in 2.0. In the case I had, it failed due to API changes from 1.1 to 2.0. You can specify which version IE will use using a config file (iexplore.exe.config I think it was called) but that setting will hold across all web pages, so that's not so great.
  Developers dislike Java's way of deprecating old APIs, figuring it leaves cruft, but if MS had deprecated what they changed and made new versions I never would have had this issue. Then again maybe my company deserves their resources being wasted this way by letting my predecessor actually write a web page using .NET client controls, but still.

Re:Just use a glove

[HJED]

the JDK7 project builds it source from it and adds in all the propitiatory software it is still in beta

Bloat?

[ttfkam]

Are you sure you're not overreacting? If you hop on over to perl.com, you'll notice that the *compressed* source of Perl 5.10.0 is 14.9MB. The compressed source of Python 2.5.2 is 11MB. Ruby 1.8.7 comes out well at 3.9MB, but that's without any gems (good or bad depending on your point of view). The source for Common Lisp 2.4.5 is 7.1MB.

However you're singling out Java as the one that's bloated? Get real.

Re:Mono needs a similar testsuite.

[Anonymous Coward]

For the iterators, think something more like this:

public class TreeNode : IEnumerable
{
      TreeNode left, right;
      int data;

      public IEnumerator GetEnumerator()
      {
            if (left != null)
                  foreach (int i in left)
                        yield return i;

            yield return data;

            if (right != null)
                  foreach (int i in right)
                        yield return i;
      }
}

Code is simple and readible. Last time I tried to rewrite something like this in Java it was kind of a headache and the resulting code was slower.

Am I missing the difference between this and java's "Object a = new SomeReallyBadDefinition();"

You can't call any interesting methods on Object. That feature is just to save some typing, though. IIRC, C++0x will introduce something similar like this to C++.

Re:bfd

[setagllib]

I also disagree with the great cost of the Java compatibility kit, but having it there at all is a great idea. It's basically one big unit test harness, and we all know unit testing is a good thing when done right. So now Sun have a unit testing framework they can use to ensure new releases really do maintain backwards compatibility, and one that alternate implementations can use to have a reasonable confidence their version of Java actually works.

Re:Mono needs a similar testsuite.

[Planetx_123]

For #1, it doesn't matter-- without runtime help you loose half of the power of generics. In either case you aren't gaining anything. Your company is still writing without generics. If a .NET shop wanted to work with 1.1 then they wouldn't write generics either... no difference. The problem is forward compatibility. You "could" write with generics and they could work with non-generified JREs. In the trade-off I would prefer the runtime benefits (et al) any day of the week.

For #4- you don't understand what you are talking about. For good uses of yield (or closures) go ask one of the millions of Ruby fans that are convinced its the best thing ever. Note that your example of "Who is John Galt" is stupid. You can write bad code in any language-- programming languages aren't meant to "fix" stupid.

For #5- you clearly don't understand how type inference works. This is still static typing- its just that the type is inferred by the compiler (obviously at compile time) instead of having the coder type extra, unnecessary characters. It is NOT a "variant" type or widened type. It is only syntactic sugar to save you some keystrokes when declaring and initializing in the same statement (which should almost be required). No one is arguing against types or interfaces, etc. This is only to help reduce some superfluous typing. And YES this is in C++0x as well.

Re:Mono needs a similar testsuite.

[rreyelts]

I'm pretty sure .NET has Java beat in several areas. For example, generics. In Java generics are just syntactic sugar for casting everything from java.lang.Object to something else. Each cast is a runtime type check, which comes at a performance penalty that I don't believe is trivial. .NET actually generates unique code without that casting.

You should read John Rose's blog [sun.com] for nice comparisons between .NET and the JVM. You give a perfect example of something that would cost .NET in performance, but that the JVM optimizes out at runtime (casts). Don't take my word for it. Put together a micro-benchmark and see for yourself. If you download a fast-debug build of the JVM, you can even see the machine code it generates for a particular method (-XX:+PrintOptoAssembly).

APIs, maybe, I don't know, but language features, definitely not.

If you want a nicer language on the JVM, use Scala [scala-lang.org].

Re:Perfomance

[dave87656]

I just tested it on Ubuntu. The fonts are not as attractive as with the Sun JDK. And the resident memory usage was about twice that of the Sun JDK.

Not sure about the speed. But first indications are that I will be staying with Sun's JDK.

Re:Perfomance

[dave87656]

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.

Huh? The whole project is 6.5 million lines. 4% comes out to 260,000 lines according to my calculator.

Re:Mono needs a similar testsuite.

[davebert]

(1) Type erasure in java generics makes writing reflective code a nightmare.

(4) Support for iterators in the language makes them a lot easier to write

(5) - in your example, a is still strongly typed, it's just that you don't have to tell the compiler what it is. The dotnet rules wouldn't let you have an overloaded function such as callThisAmbiguousReturnTypeMethod that differ only in their return type, so this wouldn't be an issue.

It's also the only way to declare a variable with an anonymous type, e.g.

var x = new {Foo = "X", Bar = 0};

(and yes, Foo and Bar are also strongly typed)

Anonymous types can only be used within the method in which they defined, and are very useful at cutting down on the profusion of crappy little data type class that you'd otherwise end up having to write every time you need a simple tuple. Personally, I use them a lot for projections over LINQ expressions.

Oh, and don't forget c# lambda expressions which can be easily be decomposed into the equivalent expression tree.

Re:Mono needs a similar testsuite.

[optevo]

I agree that Java is showing its age. C# has the advantage that is was designed several years after Java and learnt from its mistakes. Also, Java had a philosophy (for quite a while although it seems to be changing) that language changes should be made quite conservatively. However, there are some languages that run on a JVM that integrate perfectly with the Java API but have all the C# features you mention (and many more). I highly recommend looking both at JRuby [codehaus.org] and Scala [scala-lang.org].