Long time member of the Java community. Author of JHTML and the SmugMug Java API, worked with the DZone crew for a while and Product Services Manager at Genuitec. Also the creator of The "Break it Down" Blog and comedy site Up My Own Ass. Riyad has posted 6 posts at DZone. View Full User Profile

Sun's Open Source Java Right Around the Corner... doh!

06.23.2008
| 6947 views |
  • submit to reddit

News trickled out this morning that Sun is a few months out from preparing the last pieces to it's own fully Open Sourced/free version of Java -- after getting the company behind Java2D rendering technology to agree to Open Sourcing the code and decided to rewrite the sound APIs when the author company refused to play ball.

This, following last week's news that RedHat's Open Source version of Java, IcedTea, had finally passed the Java Test Compatibility Kit (TCK) which I believe is the biggest hurdle to becoming a "real Java implementation".

Given RedHat's position in the market and platform deployment reach (customers), is anyone else worried that this is the beginning of Java's fragmentation that has been discussed in the past? I doubt RedHat is going to kick IcedTea to the side in a few months after Sun releases their work. So now we have two actively developed Java platforms that are almost compatible with eachother, or compatible enough that they seem interchangable to most folks? (they never are... not a code base that big, and not with only 80k tests verifying it)

I'm normally a fan of choice, but in this case I don't see choice... I see incompatibility nightmares.

Maybe I'm just being pessimistic... anybody want to point out to me how this is awesome news? I will conceede that RedHat's announcement likely pushed up any Sun plans to Open Source the JDK, so that part probably helped, but then again I don't think Sun would have sat on their hands w.r.t. to the Open Sourcing of Java given all the fan-fair over the years... so it was coming anyway... now we just have two.

References
Published at DZone with permission of its author, Riyad Kalla. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

ff aaa replied on Mon, 2008/06/23 - 12:07pm

OpenJDk- Iced Tea has RedHat contribution. i dont underestimate their work, but most credit is Sun's here. Dont forget that %98 or more code of Iced Tea is from Sun's open JDK.

Dmitri Trembovetski replied on Mon, 2008/06/23 - 12:08pm

Sigh. What a load of misunderstandings (reading what Simon said I can't blame you though). IcedTea uses Sun's OpenJDK code, they are the same thing (sans packaging and a few things like plugin/webstart). When OpenJDK still had some encumbered stuff (the famous 4%) IcedTea used some Classpaths' pieces to replace the encumbered parts, but now that Sun got permission to open the java.awt.Color/color code, and integrated freetype font rasterizer as well as       Sun's picses antialiasing shape rasterizer, and with the outside contribution of java.sound code IcedTea can (and does to my knowledge) just use OpenJDK source with some distro-specific fixes here and there.

Dmitri

 

 

Riyad Kalla replied on Mon, 2008/06/23 - 12:14pm

Dmitri,

Not sure who you were replying to, but after Sun finishes open-sourcing the work and IcedTea becomes an even closer mapping directly to the OpenJDK, are you assuming that RedHat will can IcedTea or keep making releases to it?

My guess is that they will keep making releases for it and integrating it further into their server platform to sell a more convincing story. The problem with that is that while initially OpenJDK and IcedTea will have a 99.5% footprint overlap, at some point those code bases will start to diverge, either with proprietary hooks, enhancements or changes and that is the future that I'm so apathetic about, especially if RedHat keeps growing it's success as a server platform.

I have images of "Java EE 7" and "Java EE 7 - RHEL Edition" in my brain, and I want to cry. 

John J. Franey replied on Mon, 2008/06/23 - 12:34pm

 

First:

Here is the original announcement of IcedTea projecti:

http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/5

This announcement declares that IcedTea is not a fork. The single goal of IcedTea is to provide gpl compatible replacement for the proprietary code of openjdk. 

 

Second:

Here is quote from the IcedTea announcement you linked to:

From here the initial plans are to make OpenJDK part of Red Hat Enterprise Linux distributions starting with Red Hat Enterprise Linux 5.3 and to expand the platform support.

 

I just don't see a code fork here.  Can you point it out?  What am I missing? Why won't RedHat keep to these statements?

Thanks,

John

 

 

 

 

 

Arek Stryjski replied on Mon, 2008/06/23 - 12:36pm

[quote]I have images of "Java EE 7" and "Java EE 7 - RHEL Edition" in my brain, and I want to cry.[/quote]

But we have now on Linux: Sun Java, GJC, GNU Classpath, I think also IBM JDK, and maybe more...
Why some RedHat JDK make big difference?

Part of Linux is choice of hundreds of distributions, with different versions of same library's. If you see it as problem don't use this operating system.

Riyad Kalla replied on Mon, 2008/06/23 - 12:37pm in response to: John J. Franey

John, thanks for the links. So in a few months we will have two GPL'ed, open source Java distributions, 1 from Sun and 1 from RedHat that will be integrated into RHEL and shipped to all their customers.

That's a fork right there, and as for the issue of "well it's not a big deal, they are 99% the same code", please see my previous post about that.

Riyad Kalla replied on Mon, 2008/06/23 - 12:43pm in response to: Arek Stryjski

Arek,

GJC/Classpath and Harmony don't have the distribution power that RedHat does to actually impact a change in what Java platforms are deployed out in the field en-mass, not like RedHat does. So what wasn't even an issue before is now suddenly an issue because you have a company with a lot of money, resources and distribution channel pushing out a forked release of Java... yay :(

Sun certain has just as much of an agenda as RedHat does with Java, so I'm not saying that Sun is all goodness and light, just that as a developer I'm not thrilled to see this happening.

As far as Linux and hundreds of distributions go... uggg, you are exactly right, and look how much actual/marketable/applicable/competative work gets done in that realm. If it weren't for Canonical, RedHat and Novell forcing shape and form onto Linux, Linux would be useless to the masses.

Brendon replied on Mon, 2008/06/23 - 12:49pm

You worry too much.  Write once, debug everywhere has always been true.

Code I wrote for 1.4.0 had to be changed to work around bugs introduced in 1.4.1, then changed again when 1.4.2 came out (Introspector changes).  The Webstart implementation changed completely in 1.4.2 in non-compatible ways requiring more rewrites.  Java 5 brought more non-compatible changes.  Java 6 changed the inheritance hierarchy of JNLPClassLoader effectively removing public methods.  More rewrites.  The underlying implementation of JavaSound changed in Java 5 and the rendering pipeline in Windows in Java 6.  Apple changed their LAF in Java 6 requiring more rewrites. With that lots of bugs fixed meaning lots of:

if (System.getProperty("java.version") < 1.6) {	doWorkAround(); }

Code I'm writing now has provisions for Windows, Mac and Linux given subtle timing differences and unspecced event order differences between the platforms.

IcedTea is just another Java version.  They all have to pass the TCK and cannot add new features. 

Brendon. 

Chris Kent replied on Mon, 2008/06/23 - 1:34pm

How is this different from the current situation where (for example) IBM and BEA (JRockit) have their own widely-used Java VMs?  I don't recall hearing any horror stories about incompatibilities between Sun's VM and those so I'm not sure why it should be different in this case.  Particularly as Sun's VM is the defacto standard so RedHat would be shooting themselves in the foot if they let any incompatabilities creep in.

Riyad Kalla replied on Mon, 2008/06/23 - 2:07pm in response to: Brendon

Brendon,

Those are pretty good pts, each major release (Even minor patches) have brought about debug-inducing changes over the years... but all of those have been from one company which I think lessened the burdon.

As far as "They all have to pass the TCK and cannot add new features", I don't think that's correct. If RedHat licenses the "Java" name from Sun, it's true that it has to pass the TCK and maybe then it has to be API compatible... but RedHat isn't licensing the Java name, so I'm pretty sure they can do what they want (e.g. proprietary RHEL system hooks, admin tool hooks - vm management, etc. etc.)

Maybe I'm wrong though?

Riyad Kalla replied on Mon, 2008/06/23 - 2:11pm in response to: Chris Kent

Chris,

There is a bit of difference between VM (the thing that runs the byte code) and Java platform (all those libs that make up the platform), but in the general case (incompatible things) I think your point is valid and there are incompatabilities across those VMs that make some things a real pain the ass to work with.

For example, IBM VM can run Eclipse out of the box, but there are certain combinations of Eclipse Plugins that once added, won't run except with the Sun VM because of some black magic/classpath/native code interactions that occur down in the depths of hell.

Maybe not a big deal for everyone, but those issues are there and it would be nice if they weren't, e.g. if the VM was provided open-source from 1 company and there weren't a lot of different choices/versions of them where little niggling things like that can popup on you.

But again, I don't think the differeing VMs is the end of the world, but I think having entirely different forked platforms is the beginning of maybe not the awesomest thing ever?

Dmitri Trembovetski replied on Mon, 2008/06/23 - 3:07pm in response to: Riyad Kalla

> but I think having entirely different forked platforms is the beginning of maybe not the awesomest thing ever?

Can you please explain again how did you jump from "99% of the same code" to "having entirely different forked platforms"?

Having and maintaining your own fork of a very complicated product such as the JDK is extremely hard. It is in the interest of whoever is maintaining the distro branches to keep their version as much in sync as possible. That is why whatever changes Redhat or anyone else makes will be pushed into the main tree asap.

And again, they will still need to pass the TCK. 

I think your fears of of diverging platforms are unfounded.  If anything this will greatly help Java's penetration since Redhat will be doing and maintaining ports to the platforms and architectures that Sun would never have the resources to even look at. So now people would be able to use a much more compatible implementation on Sun-unsupported platforms.

So no, I don't think the sky is falling. 

Dmitri 

 

Kevin Daly replied on Mon, 2008/06/23 - 3:12pm

I think that OpenJDK and IceTea are going to be merged, or simalar to how the linux kernel is distributed. Red Hat will be the downstream recipient to Sun's OpenJDK, it wouldn't be in Red Hats best interest to fork from the Sun OpenJDK, so once Sun's implementation is available, IcedTea will consume that code instead of merging in ClassPath code or others.

I wish I could find the article, but one of the IcedTea developers stated that it was only supposed to be temporary until an unencumbered version of the JDK was available.

Bruno Laturner replied on Mon, 2008/06/23 - 3:49pm

Both codebases must pass the TCK tests.

If after that the code is still incompatible, then new TCK tests must be made, and again they must pass the TCK. Repead ad infinitum.

Two codesbases don't generate incompatibility nightmares, they actually help to make a more compatible platform, that is, if both codebases primary objective is standardization.

Brendon replied on Mon, 2008/06/23 - 6:33pm in response to: Riyad Kalla

Yep.  You're wrong.  Android is a fork, but then that's why it's called Android with nary a Java(TM) to be seen.  You change an API, the TCK will fail and then it's not Java.  I'm pretty sure you can't add a feature either, although doing so would be identical to shipping a rehat_system.jar which anyone has any right to do anyway.

Jeroen Wenting replied on Tue, 2008/06/24 - 1:07am

It can lead to problems if RH leverages their distribution power to force non-compliant versions onto enough machines to place Sun in a position where they either have to bow to RH and change the language spec to match what RH wants it to be or loose so many installed machines that the Java name becomes irrelevant (which will cost them dearly).

 IBM tries to do that through the JCP and Eclipse (which has compatibility problems) and so far has failed to achieve that market penetration because their installed base is relatively small.
If RH can get their version out on every RPM based Linux distribution they'll have it on pretty much every lowend and midrange server out there, plus a smittering of workstations.
Customers will start screaming about their Sun JDKs on Windows being "incompatible" with their RH server JVMs, and demand Sun "take action to fix their bugs" when in fact it's not Sun who's at fault at all.
This happens to some degree with Eclipse as well, though there it's easy to point to the Eclipse compiler as (sometimes) producing flawed classfiles, and it's the Sun JVMs that have the market cornered still.

In all, I don't see a very rosy future. Instead I see a powerstruggle between Sun, RH, and possibly IBM for control over the Java platform and its specifications, a struggle that may well fracture the platform to the point of no return.

Michael Bien replied on Tue, 2008/06/24 - 4:19am in response to: Bruno Laturner

[quote]If after that the code is still incompatible, then new TCK tests must be made, and again they must pass the TCK. Repead ad infinitum.[/quote]

agread.

In theory, but in practice there are bugs. And bugs can't be integrated in all distributions in parallel (or at least thats how it currently works in the openjdk6/7 and update 10 branches - it looks for me more or less randomn) and many of them are also not verifyable through automatic test (concurrency-, deployment-, graphics bugs).

The result is that you will have earlier or later to test your desktop app against all main distributions and apply distribution dependent workarounds.

 

Riyad Kalla replied on Tue, 2008/06/24 - 8:54am in response to: Jeroen Wenting

Jeroen,

I couldn't have said it better myself, that is exactly the problem.

John J. Franey replied on Tue, 2008/06/24 - 9:54am in response to: Jeroen Wenting

 

if RH leverages their distribution power to force non-compliant versions onto enough machines

 

There is no such power in this case.

If RH puts dependencies on their java in jboss, hibernate, seam or their other java based projects, then these would no longer run on any windows or non-RH distro.  Meaning, in order to use hibernate, users and developers would HAVE to load RH's java, even if when using on windows or mac.  Users will not do this.

RH has zero leverage on many other java projects: apache (tomcat, commons, ...), jvm based languages (groovy, jruby, scala, ...), IDE (eclipse, netbeans, intellij, ...), web servers (too many), databases (derby, hsql, ...), and thousands of other useful java libraries, utilities and applications.  These projects will not change their code to use RH extensions.

If RH's java is not consistent with openJDK to the point of breaking other java projects, users who own support contract would require RH to fix the RH java, or they would find another support vendor for java.

Users who are not interested in support contract will simply uninstall RH java and install openJDK.

Thanks,

John

 

 

 

Riyad Kalla replied on Tue, 2008/06/24 - 10:05am in response to: John J. Franey

Meaning, in order to use hibernate, users and developers would HAVE to load RH's java, even if when using on windows or mac.  Users will not do this.

Yes they would, people do this all the time. Your assumption that these developers that have contracts with RedHat for their hardware, software, support, etc. wouldn't make use of proprietary extensions that save themselves time just because it's not platform compatible with Windows and Mac is just not accurate.

This might be the case in some companies that have tech gurus at the helm that value this sort of stuff, but for the mass majority of companies that just have problems to solve, they won't care where the extensions come from.

RH has zero leverage on many other java projects: apache (tomcat, commons, ...), jvm based languages (groovy, jruby, scala, ...), IDE (eclipse, netbeans, intellij, ...), web servers (too many), databases (derby, hsql, ...), and thousands of other useful java libraries, utilities and applications.  These projects will not change their code to use RH extensions.

No one said they would... I don't really understand what you were trying to say here.

If RH's java is not consistent with openJDK to the point of breaking other java projects, users who own support contract would require RH to fix the RH java, or they would find another support vendor for java.

If they own support contracts with RedHat, the only version of Java RedHat is going to cover with that contract is IcedTea, which means this is exactly what they won't be doing. They are never going to install OpenJDK and find out their code is incompatible because it's not covered under the support contract.

Jesse Sightler replied on Tue, 2008/06/24 - 11:14am

I hereby doth solemnly declare that this is the silliest thread of the week. We currently have the following major Java implementations (TCK-grade here... not the Harmony or GCJ stuff... and in common use):

 - Sun's Java (various versions)
 - IBM's Java (has been popular at times, now just popular with IBM customers)
 - Blackdown Java (used to be popular on Linux, now not so much)
 - Apple's Java (Mac)

After years of all of this, you are worried about an openly developed Java that is 99% Sun code, with the stated goal of being as close to 100% Sun code as is possible (while not hurting stability or shared lib compatibility on their Linux distro)?

You are, of course, correct that the variations cause some degree of pain for several reasons. Yes, sometimes they have bugs that cause code not to work across VMs, and yes sometimes people use platform classes that they should (eg, people using sun.* packages, and the goofballs at Sun that occasionally even endorse when they shouldn't). But we've dealt with that for years, and the branches have often been populer, so this is absolutely nothing new. Most of the time when things break, we file bugs against the Java distro that broke things and it gets fixed in short order.

So, this "DOH" is just descriptive of the world we've been in for the last 8 years. Why bring it up now?

Simon Phipps replied on Tue, 2008/06/24 - 11:25am

To be clear, the "news" stories that are causing the confusion are way out of date - they relate to interviews I gave while I was in Australia a month ago which for no obvious reason dripped out as if they were new news. OpenJDK is integrating contributions made by the IcedTea folks and there is exactly one code-base. Please see the posting I recently made on my blog.

Riyad Kalla replied on Tue, 2008/06/24 - 11:35am in response to: Simon Phipps

Simon that is excellent news, thanks for posting the clarification.

John J. Franey replied on Tue, 2008/06/24 - 1:14pm in response to: Riyad Kalla

 

 "running off" with java would be especially difficult for RH.  Their own java applications/tools would be victims of their own java fragmentation.

Potential customers will ask which java applications are supported by contract on RH java, so RH will have to maintain a list of certified apps, much like they do with hardware platforms.  RH will have to pay for a certification process and charge customers for it directly or through support contracts.  This results in a higher cost to for customers.

RH java apps/tools would not run on anything but RH java.  The assumption here is that hibernate, jboss, seam and the like have been modified to take advantage of the RH extensions.  This would prevent these tools from being run on any other java platform reducing revenue for RH which offers support contracts for these products.

RH will have to fork/modify and support open source java projects if customers require the java product, and the projects' teams do not agree to make necessary changes.  This increases cost to RH customers, and reduces the amount of available software to their customers.

 

So, I agree with Jesse Sightler, this is a silly thread.  Its silly to be fearful of this. I am greatful to Simon Phipps for the clarification.

 

 

Rich Sharples replied on Tue, 2008/06/24 - 2:11pm

Just to be clear - this isn't an attempt to fork Java - I can't imagine where such a wild idea came from. We have a thriving business that depends on Java.

 I realize that asking people to RTFA is futile but here goes anyway :

 

Fedora / OpenJDK announcement : http://blog.softwhere.org/archives/196

Addressing popular misconceptions : http://blog.softwhere.org/archives/199

 

Rich Sharples

JBoss, a division of Red Hat

Riyad Kalla replied on Tue, 2008/06/24 - 2:26pm in response to: Rich Sharples

Rich,

I don't think it's unfair of people to assume that RedHat, at some point, may try and make a business case for their version of Java over the standard OpenJDK distribution.

RedHat padi $350 mil for JBoss, JBoss has quite a bit of development invested in an application server stack, JSF, and some home-grown JSF based technologies, tags, components, etc. and the tools as well.

To imagine a future where RedHat begins shipping a RHEL-specific Java Server stack that cannot drop directly into say a Glassfish 2/3 container run under Java 7 isn't far fetched... I doubt any of the business minds at RedHat sit around thinking "OMG we better not piss of the community", if they can find a business case for vendor-specific tie-in (and eventually lock-in) to their platform, they'll do it.

I'm not suggesting that's a bad thing, some proprietary technologies really do  help companies save time and money. I do feel that unless RedHat abandons IcedTea and just re-centers on OpenJDk exclusively at some point, I'm not ruling out the possibility that in the future there will never be a fork, no matter how small, between OpenJDK and IcedTea.

And again... I'm not advocating that they do this, I don't care what they do... the deserve to make money just as much as the next guy, I'm just providing insight into why I think the posturing behind your own Java platform is more significant than some hand-waving and unicorn-goodness to suggest that a fork will never happen.

Rich Sharples replied on Tue, 2008/06/24 - 3:42pm

There is a reasonable point here but I think it's obfuscated somewhat by the assumption that Java and openJDK are the same thing; they're not - one is a specification, the other is an implementation of that specification.

I can think of only a few reasons why anyone would fork Java (the specification) - and none of them are interesting to Red Hat. We have a decent business built on Java - ie. Java workloads running on RHEL and JBoss. If our Java doesn't work like everyone else's Java then we have a buggy Java and customers will make us fix it or they'll (continue) to use someone else's.

However, I *can* think of lots of reasons why we'd improve openJDK in ways that are specific to RHEL or Linux - I enumerated these in my original blog post - but there's nothing sinister here - these are the kind of optimizations that *all* jdk licensees make - the extreme example being Azul; ie. they need an optimized JVM for their unique processor architecture. The difference with our improvements (should we ever make them) is that they will be made available to the upstream project so everyone can benefit. Some of those improvements will be generally relevant and will be accepted; some, no doubt, won't.

So at some point in the future we might technically be maintaining a fork. But it's a fork of the openJDK project, not a fork of Java. Our distribution of Java will still have to pass the Java TCK and will still have to be capable of running Java applications - if it doesn't, it really isn't going to be much use to anyone. It's probably worth repeating - what defines Java is the specification, the Java TCK and the millions of applications written to the specification.

I would also expect - because Red Hat's Java will be largely based on Sun's (which is by far the most popular) we'd be significantly more 'compatible' with the rest of the Java world (ie. bug for bug level compatibility). 

 

Rich Sharples

JBoss, a division of Red Hat

 

Simon Phipps replied on Tue, 2008/06/24 - 3:34pm in response to: Riyad Kalla

unless RedHat abandons IcedTea and just re-centers on OpenJDk exclusively at some point

Again, to be clear, it is my belief that Red Hat and the Fedora and Classpath teams working on "project codename IcedTea" are an integral part of the OpenJDK community and as such your "unless" has already happened.

Jesse Sightler replied on Tue, 2008/06/24 - 3:59pm in response to: Riyad Kalla

[quote=rkalla]

Rich,

I don't think it's unfair of people to assume that RedHat, at some point, may try and make a business case for their version of Java over the standard OpenJDK distribution.

[/quote]

Actually, I think that it is very unfair to assume that.  People with a much larger business interest in that than Red Hat ever could have already choose not to do that (IBM, BEA).  Why would Red Hat ever make such a decision?  Locking people in by changing the JDK would only lock things out (free and commercial libs) that would hurt them.

OTOH, developing an app server stack on top of the JDK that is outside of the JEE standards is in vogue these days, and is something for which a business case could be made.  Its hard to twist that into scenario a bad thing for Java or a "fork", though (especially considering that Red Hat's history suggests it would be open source).

Brendon replied on Tue, 2008/06/24 - 4:10pm in response to: Riyad Kalla

FUD.  I think you're possibly insulting the intelligence of an entire community; especially the standards-obsessed Java community.  If it doesn't pass the TCK, it's not Java.  If it's not Java, no-one will use it.  If they add features, then so what?  You don't need to fork and maintain 6.5 million lines of code to this.  Just ship a JAR file with JNI in it.  If it's a useful JAR file, it will lock people in.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.