LWN.net Logo

OpenJDK is Zombie project

OpenJDK is Zombie project

Posted Aug 14, 2010 10:20 UTC (Sat) by nim-nim (subscriber, #34454)
In reply to: OpenJDK is Zombie project by khim
Parent article: Oracle sues Google over use of Java in Android (ars technica)

> Just like all other Oracle projects OpenJDK is zombie project

Not really. It's only a zombie project if:
1. Oracle tries to push new changes in Java 7
2. Oracle somehow refuses the associated TCK checks to OpenJDK

And guess what? Sun has mismanaged Java so badly, and Java 7 has slipped so often, I doubt "I can do Java 7 but you're stuck with Java 6" would matter a lot for the customers that use big J2EE apps

In fact they'd probably be happier with a "OpenJDK is still Java 6, but with the SUN bugs fixed" JVM.


(Log in to post comments)

It's zombie project because it makes no sense to keep it alive...

Posted Aug 14, 2010 10:50 UTC (Sat) by khim (guest, #9252) [Link]

In fact they'd probably be happier with a "OpenJDK is still Java 6, but with the SUN bugs fixed" JVM.

Well, that's the definition of zombie project, isn't it? OpenJDK was already in bad shape, but lawsuit made it literally the "living dead": it's covered by GPL so Oracle can't take it away, but it makes absolutely no sense for anyone except Oracle to try to extend it and keep it alive. Everyone else will only ever supply small bugfixes...

Over time it'll become less and less relevant and will probably shrink and die. But yes, it'll take years.

It's zombie project because it makes no sense to keep it alive...

Posted Aug 14, 2010 11:30 UTC (Sat) by paulj (subscriber, #341) [Link]

That doesn't make sense. We now know that anyone who wants to develop a JVM (or similar) has to worry about 2 kinds of Oracle patents:

1. The patents on things implemented already in the JDK

2. Other patents, which are not implemented in the JDK, some or all of which may be unknown, some or all of which may be irrelevant to JVMish developers.

For the former class of patents, you can *get* a licence from Oracle via the GPL, and that licence extends to derivation through modification of the work.

For the latter class, you have to either avoid them or get a licence from Oracle for the known ones that are applicable to you - the unknown ones you can do little about. You're in that boat regardless of whether or not you use GPL OpenJDK.

Surely the rational choice now would be for any future developers to ensure that at least Oracle can't shake you down on the former class, i.e. base work on the OpenJDK?

Sorry, but no...

Posted Aug 14, 2010 12:14 UTC (Sat) by khim (guest, #9252) [Link]

For the former class of patents, you can *get* a licence from Oracle via the GPL, and that licence extends to derivation through modification of the work.

There are two patent grants. One (implicit) does not extends to derivations (this is known GPLv2 loophole). Another is explicit - but it's only available for the "compliant implementations" which "pass all test suites". And said "test suites" are not open source, they are not available without written permission and so this promise is essentially pointless.

Surely the rational choice now would be for any future developers to ensure that at least Oracle can't shake you down on the former class, i.e. base work on the OpenJDK?

No. The rational choice is to drop Java ASAP. Java is new COBOL: useful for legacy systems, but quite pointless for the new development. You can continue to use it - but only as long as you base your work on modified (or slightly modified) OpenJDK.

This is beginning of the end for Java.

Sorry, but no...

Posted Aug 14, 2010 18:14 UTC (Sat) by paulj (subscriber, #341) [Link]

This is an interesting theory, that the GPLv2 implicit grant doesn't extend to derivation. I think you must be utterly wrong on that, for the GPLv2 explicitly grants you the right to modify. So therefore, for any processes that are implemented within the code for which you receive an implicit GPLv2 patent grant, you must be able to modify the code implementing that process and retain the grant - that's what the licence tells you you may do, after all.

Perhaps there is some fine line you have to walk to stay within the bounds of "modification", and not appear to be a new implementation. A new implementation would, obviously, not be covered by such grants.

As for the TCK grant, I never referred to that all.

I see we're actually agreed now that this means future Java work pretty has to be on the OpenJDK, in order to be safe from Oracle lawsuits. Whether this means Java is doomed though, I don't know. As others have pointed out, perhaps if anything it means that the only way to be safe, if you want a Java style runtime, is to seek shelter in the corporate patent thickets erected around the Java JVM and C# CLR.

It will be interesting to see how this lawsuit pans out. On the one hand, if Google contested it and found a way to have it ruled these patents do not apply, then it would benefit everyone. OTOH, the easiest way out for Google perhaps is to settle and pay off Oracle (but would that mark Google out as an easy touch for trolls?).

It's zombie project because it makes no sense to keep it alive...

Posted Aug 14, 2010 12:32 UTC (Sat) by nim-nim (subscriber, #34454) [Link]

Java as a language is pretty mature and good enough for decades. If Oracle wants to be a nuisance, they can try to use legal threats to freeze the OpenJDK feature perimeter (so others will miss on the language changes planned for Java 7), but anyone can "extend" the JVM via additional out-of-JVM libs.

Oracle's grip on the JVM depends on competitors actually using the bits it adds in new Java standard versions. It used to matter because there was no sane way to deploy additional java components, but OSGi has solved this part, so if Oracle wants to play hardball all they'll win is increased adoption of OSGi (when SUN pushed another mechanism for Java 7) and increased use of out-of-jvm java libs (which will marginalise Oracle features outside Oracle apps)

Eclipse showed nicely that as long as a JVM with basic capabilities was available, everything else could be bolted on with additional components. That's why every big SUN Java project failed BTW: competitors didn't like the power SUN already had JVM-side, so they deliberately chose not to support its other Java initiatives. (that's what SUN got for being a control freak and frightening other players)

Well, it's was in Sun's era, this is now Oracle era...

Posted Aug 14, 2010 12:53 UTC (Sat) by khim (guest, #9252) [Link]

If Oracle wants to be a nuisance, they can try to use legal threats to freeze the OpenJDK feature perimeter (so others will miss on the language changes planned for Java 7), but anyone can "extend" the JVM via additional out-of-JVM libs.

Well, as long as Oracle does not feel said extensions threaten it's control...

It used to matter because there was no sane way to deploy additional java components, but OSGi has solved this part, so if Oracle wants to play hardball all they'll win is increased adoption of OSGi (when SUN pushed another mechanism for Java 7) and increased use of out-of-jvm java libs (which will marginalise Oracle features outside Oracle apps).

Well, it's one of reasons for lawsuit, isn't it? It does not matter if you have OSGi or not if you can not legally use your extension.

Eclipse showed nicely that as long as a JVM with basic capabilities was available, everything else could be bolted on with additional components.

Well, if you are IBM, then yes. Even Oracle will not blindly attack the IBM with patent-related subpoenas.

That's why every big SUN Java project failed BTW: competitors didn't like the power SUN already had JVM-side, so they deliberately chose not to support its other Java initiatives. (that's what SUN got for being a control freak and frightening other players)

Yup. But Oracle changed rules of game: it's "my way or the highway" now. Only gorillas like IBM may be safe... for now.

Well, it's was in Sun's era, this is now Oracle era...

Posted Aug 14, 2010 13:25 UTC (Sat) by nim-nim (subscriber, #34454) [Link]

Oracle inherited from SUN some patents on core JVM features.

It can not use those patents to attack a JVM core SUN already blessed (OpenJDK), it would be laughed out of court (even if the GPLv2 implicit patent covenant was not affirmed)

It can not use those patents to attack out-of-JVM Java libs, because they're about core features, which are already provided safely by OpenJDK

Also, because the purpose of a JVM is to run Java code, they can not attack people for doing so, even if some of this code is used instead of the in-JVM classes Oracle would prefer people to use (that is, they can not attack using their JVM patent portfolio, they can attack using other patents but this would apply to any software)

What IBM did with Eclipse (and anyone else can do) was very smart: use a compliant JVM that includes stuff like swing (and that Sunacle can not sue about), but not use swing in the app and rely on out-of-jvm swt instead.

It's completely different from the Dalvik/Harmony case where the JVM core was never approved, and where changes were done Google-side in core JVM features (so either it's a JVM, and Oracle can attack it via the TCK, or it's not, and the patent pledge does not apply)

Funny, it's exactly why Oracle is doing...

Posted Aug 14, 2010 14:24 UTC (Sat) by khim (guest, #9252) [Link]

It can not use those patents to attack out-of-JVM Java libs, because they're about core features, which are already provided safely by OpenJDK

Of course it can! These are unlicensed implementations of core features and that means this is "willful and deliberate infringement" which should be stopped right away. Isn't it what Oracle does right now with Dalvik? So one step from OpenJDK implementation - and you are the target.

Also, because the purpose of a JVM is to run Java code, they can not attack people for doing so, even if some of this code is used instead of the in-JVM classes Oracle would prefer people to use (that is, they can not attack using their JVM patent portfolio, they can attack using other patents but this would apply to any software)

Newsflash: this exactly what they are doing right now. You only covered in two cases:
1. When you use OpenJDK (and if you modify it too much you'll lose the protection), or
2. When you've passed TCK tests (and rules for these tests change all the time - when Apache asked Sun asked to exclud mobile Java, for example).
People talked about these loopholes for years, but it was a moot point because Sun was interested in litigation. Oracle is very interested as you know.

What IBM did with Eclipse (and anyone else can do) was very smart: use a compliant JVM that includes stuff like swing (and that Sunacle can not sue about), but not use swing in the app and rely on out-of-jvm swt instead.

1. That's good way to create slow "enterprise" monster - and this where Java will live long life. Normal, small and nimble applications? Fugetaboutit!
2. It only works for IBM because Oracle will not dare to sue them about SWT. Smaller fishes can be easily killed.

It's completely different from the Dalvik/Harmony case where the JVM core was never approved, and where changes were done Google-side in core JVM features (so either it's a JVM, and Oracle can attack it via the TCK, or it's not, and the patent pledge does not apply)

TCK only applies to implementation which pass tests. Tests may include different restrictions (including field-of-use restrictions) - this was Apache's grief for years. Basically all this means "my way or the highway" (Microsoft/C# style) and we should treat Java accordingly.

Just like we are trying to remove C# from our distributions we should plan to do the same with Java. It's as simple as that.

Actually Java is an easy case. It's much harder to remove OpenOffice.org and/or Berkeley DB...

Funny, it's exactly why Oracle is doing...

Posted Aug 14, 2010 14:52 UTC (Sat) by nim-nim (subscriber, #34454) [Link]

> Of course it can! These are unlicensed implementations of core features

No because out-of-JVM Java libs needn't provide those features since they are available through OpenJDK. The patents Oracle uses are only useful against someone that needs to reimplement core features because he has not access to a blessed JVM. They are useless against out-of-JVM Java libs that provide different features.

>> Also, because the purpose of a JVM is to run Java code, they can not
>> attack people for doing so
> Newsflash: this exactly what they are doing right now.

Nope, they are attacking Google for creating something that runs Java code, but is not a JVM by their definition. This is not a problem for OpenJDK.

> 1. That's good way to create slow "enterprise" monster

Don't be silly, remember how old Java is? Today's smartphones are faster than the computers used when Java was created. Whatever inefficiencies exist in OpenJDK will be made increasingly irrelevant as hardware gets faster.

> 2. It only works for IBM because Oracle will not dare to sue them about
> SWT.

Nope, it works because SWT is an *addon* and Oracle can only use SUN-inherited tricks to sue on core features. Google messed with core features, which is the only bit SUN had some hold on.

> TCK only applies to implementation which pass tests. Tests may include
> different restrictions

New restrictions can not apply to past approvals. They can try to play this kind of trick, as long as OpenJDK behaviour does not change significantly I doubt a judge will be impressed (yes your honour, you see, when OpenJDK passed the TCK this function returned 6 in 10s, now it returns 6 in 5s, obviously OpenJDK needs to pass TCK again, and BTW the new TCK conditions say the old OpenJDK could not have passed it either).

As long as OpenJDK does not pretend to a Java level it has not passed the TCK for before, and has not changed the behaviour that made it pass the TCK previously, it's clean. (and that's only about the Java name, it Oracle tried patent tricks they'd have to handle the GPLv2 implied patent grant before a judge, which is a lot less easier than threatening to do it someday before the press).

Oops...

Posted Aug 14, 2010 15:26 UTC (Sat) by khim (guest, #9252) [Link]

The patents Oracle uses are only useful against someone that needs to reimplement core features because he has not access to a blessed JVM. They are useless against out-of-JVM Java libs that provide different features.

Ah, I misunderstood you - I though we were talking about reimplementation of core features... If we are talking about some features not implemented in Java core then it's even easier: Sun never promised to license patents for these so if you step on Oracle's toes it's even easier to sue you. If you develop something totally unrelated to bazillion of Oracle-developed Java products then yes, you are free. The same as with C#, really.

Nope, they are attacking Google for creating something that runs Java code, but is not a JVM by their definition. This is not a problem for OpenJDK.

They are attacking "unblessed" implementation. I doubt if you'll bundle your implementation with OpenJDK it'll satisfy them. The only way to implement Java from now on is to use unmodified (or slightly modified) OpenJDK.

Don't be silly, remember how old Java is? Today's smartphones are faster than the computers used when Java was created. Whatever inefficiencies exist in OpenJDK will be made increasingly irrelevant as hardware gets faster.

There are one problem with this idea: hardware stopped "getting faster". CPUs reached 3GHz eight years ago. Today they still can not pass 4GHz barrier. The speedups now are related to increased number of cores - and as number of cores grows NUMA-related problems become more and more relevant. To solve this kind of problems you need deep redesign of system code and VM. Exactly things Oracle now forbids.

Nope, it works because SWT is an *addon* and Oracle can only use SUN-inherited tricks to sue on core features. Google messed with core features, which is the only bit SUN had some hold on.

It may be an addon, but it duplicates functionality of SWING and so probably infringes some SWING-related patents. Oracle does not dare to sue IBM but will sue any small company if it'll try to duplicate the trick.

New restrictions can not apply to past approvals.

And this means (again) that we are in zombie-state: existing implementation can be used, future development is forbidden.

As long as OpenJDK does not pretend to a Java level it has not passed the TCK for before, and has not changed the behaviour that made it pass the TCK previously, it's clean.

No, it's not. I gave the link before. You must "pass all test suites relating to the most recent published version of the specification", not some arbitrary version in the past.

and that's only about the Java name, it Oracle tried patent tricks they'd have to handle the GPLv2 implied patent grant before a judge, which is a lot less easier than threatening to do it someday before the press

And this is about zombie-state again. Yes, existing implementation is clean and as long as you don't muck with it too much you can use it. But Java development is stopped. Frozen. Halted. Java is zombie - not yet dead, but no longer alive.

And this is in the time where "multi-core revolution" means all platforms must evolve to stay relevant in a few years.

Oops...

Posted Aug 14, 2010 17:46 UTC (Sat) by nim-nim (subscriber, #34454) [Link]

> And this is about zombie-state again. Yes, existing implementation is
> clean and as long as you don't muck with it too much you can use it. But
> Java development is stopped. Frozen. Halted. Java is zombie - not yet
> dead, but no longer alive.

You continue spreading confusion by mixing different things under the "Java" name. What people call "Java" is actually three things

1. A JVM. This is the part which has been patented by SUN, and rewritten by Google. OpenJDK is safe here due to A. Sun patent pledges B. GPL implied patent licence. Google, not, because it has neither (as long as a court thinks software patents, or those software patents in particular are valid)

2. Classpath libraries. The bits of Harmony Google use are here. With 1. this is the perimeter the TCK checks. Again OpenJDK is safe here since it already passed the TCK and only needs to be careful to not change its functional behaviour. Yes you need to use the latest TCK when you pass it but no Oracle can not change the TCK and argue before a judge it invalidates its previous approval. New TCK versions are only relevant if OpenJDK wants to claim a new compliance level. And the TCK only controls the Java name, without the TCK one just has to rename its implementation, as long as the patents protecting 1. are either invalidated or procured through the GPLv2 like is the case for OpenJDK

3. Third party infrastructure libraries. Used not to be realistic because of the abysmal manual classpath system SUN set up. Hence SUN's lock on Java, you had to push your lib in the Classpath libraries to have it widely distributed and used. Lock no longer operative now others built real dynamic dep systems (OSGi, maven...)

People build Java apps over 1. 2. and 3. With OpenJDK/GNU Classpath SUn has relinquished its hold on 1. and 2. and there is no possibility of coming back. The worst Oracle can to is hamper the evolution of 1. and 2. in OpenJDK, which will just push new features in 3. And 1. + 2. + 3. is not a zombie but an operational evolving platform

Where is confusion?

Posted Aug 14, 2010 18:37 UTC (Sat) by khim (guest, #9252) [Link]

You continue spreading confusion by mixing different things under the "Java" name. What people call "Java" is actually three things.

Perhaps even more, but what this has to do with anything?

1. A JVM. This is the part which has been patented by SUN, and rewritten by Google.

Yup. This part of "off the limits" now.

2. Classpath libraries.

Frozen too.

3. Third party infrastructure libraries... Lock no longer operative now others built real dynamic dep systems (OSGi, maven...)

Yup. You can play in this space as long as you either big enough to ward inevitable Oracle attacks or if you like to live on the minefield. Oracle already showed that it will try to kill any development which threaten it's proprietary Java offers so you can safely add anything to "3" if and only if these additions have no significant value. Why bother with these additions then?

The "rotten core" model. When the traditional "open core" company stifles community the said community can at least fork the project - but here this ability is removed from the start. You can not change core no matter what. You will be sued if you want to move something from proprietary periphery to core. Even if you reimplement it from scratch. In short: the place to be only if you are masochist and like pain and like to see your "babies" killed repeatedly. Do you really think population of masochists is big enough to keep Java alive?

If the "open core" is bad (and often leads to zombie projects where community refuses to participate) "rotten core" model is infinitely worse (and almost guarantee "zombie" status in the near future). In a sense we've back in 2005 with one small difference: where Java was "all the rage" back then it's "tired old technology" now. Where back then people hoped for the future where Java will be truly open today all the hope is lost. In short: Java joined COBOL. I don't think this is what Oracle had in mind, but this is what it done.

This approach was tried many times in the past - and failed many times too. Sometimes community was able to boot "rotten core" from the project and replace it with truly "open core" (GNU/Linux replaced GNU/Solaris and now Google tries to replace JVM with Dalvik in similar fashion), sometimes community was killed instead (for example Darwin and now OpenSolaris), but this situation rarely continue for very long...

The worst Oracle can to is hamper the evolution of 1. and 2. in OpenJDK, which will just push new features in 3. And 1. + 2. + 3. is not a zombie but an operational evolving platform.

No. Oracle already effectively frozen third-party development in "1" and "2" (more effectively then Sun was able to do with OpenOffice.org - I doubt we'll see analogue of Go-OO after this fiasco) and since development of "3" will be under constant threat from Oracle too... there are only two choices: Google wins fight for Android and OpenJDK is replaced with something else (don't necessary Dalvik - it can be completely different implementation like GCJ or something similar) or Google loses and Java becomes true zombie which disintegrates in time.

Oops...

Posted Aug 16, 2010 14:53 UTC (Mon) by nye (guest, #51576) [Link]

>1. A JVM. This is the part which has been patented by SUN, and rewritten by Google.

Practically speaking, it's highly unlikely that any VM, regardless of the targetted language[0], doesn't infringe some of Oracle's patents. Since - unlike Sun - they've shown that they intend to use them, this means that nobody implementing a VM-based language is safe; we just need to hope that Oracle will only bother with deep-pocketted targets. Google obviously made themselves a big target by touting their Java-to-Dalvik compiler.

[0] Unless it's a compliant JVM *and is certified compliant by Oracle's arbitrary choice of test*.

Oops...

Posted Aug 16, 2010 16:03 UTC (Mon) by paulj (subscriber, #341) [Link]

There's another way, besides your 0: Base your VM (it need not be Java compatible) on the GPLv2'd OpenJDK and ensure any code embodying Oracles' patents stays within scope of the GPLv2 patent grant.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds