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."
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.
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?
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.
But at least its only a mountain :-)
.NET has bundled in. Especially since its taken far less seriously than Java by this community.
I don't know if Mono can ever catch up to the whole mountain range that
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...
Of course, we can search for enlightenment ourselves!
OpenJDK FAQ
Cheers!
http://en.wikipedia.org/wiki/List_of_JVMs
Javascript + Nintendo DSi = DSiCade
I was under the impression that OpenJDK was the Sun JDK7 project.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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
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
I'm not not licking toads.
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 =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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).
.Net.
Right now on my dev box I have 4 versions of
They run side-by-side without issue.
There is no forced upgrade. It's like saying that C wasn't predictable because C++ emerged.
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.
mcgrew's razor: Never attribute to stupidity that which can be explained by greedy self-interest
- 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...
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.
the JDK7 project builds it source from it and adds in all the propitiatory software it is still in beta
null
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.
- I don't need to go outside, my CRT tan'll do me just fine.
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.
Sam ty sig.
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.
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.
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.(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.
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 and Scala.