the problem is that Sun/Oracles patent license only covers implementations that passed TCK.

Conversely, by not passing TCK you don't get their patent license. Many of the patents in question are difficult (if even possible) to work around if you were to create your alternate implementation.

This means that using any non TCK implementation of Java makes you liable for patent lawsuits (as seen with the Google case).

Ah, so anyone using GCJ in a product could be sued the same way Google was sued. I didn't know that.

The right conclusion to make seems to be that software patents are bad.

    > Ah, so anyone using GCJ in a product could 
    > be sued the same way Google was sued. I 
    > didn't know that.

this is exactly the point. And this might also be (one of) the reason(s) why Google PR is calling the suit against them a suit against Open Source in itself.

The other conclusion would be that Sun, and now Oracle, are schizophrenic hypocrites: let's not blame it solely on software patents.

I believe the GCJ is vulnerable because, like Dalvik, it's not derived from the OpenJDK.

Well, not being VM based it should be free of some or all of the patents used by Oracle in that part of its lawsuit against Dalvik, but that doesn't mean that it wouldn't be otherwise vulnerable.

And don't forget OpenJDK derivatives are only patent-proof for patents owned by Sun at the time of its licensing.

> the problem is that Sun/Oracles patent license only covers implementations that passed TCK.

Can they do that, being the OpenJDK GPL-licensed? IIRC, it shields the OpenJDK, as well as GPL-licensed derivatives, from patent lawsuits.

It doesn't protect Apache/MIT/BSD-licensed implementations, but who cares, if there is a GPL-licensed implementation available?

you are right, derivates of OpenJDK are shielded.

Clean-room reimplementation are not though.

Harmony was created to have a non-GPL implementation (and was used by Google for that reason)

If, for no other reason, we should love the GPL for rendering Oracle toothless. :-)

unless they don't TCK certify OpenJDK 7. Then we're back at square one.

No. As long as it's OpenJDK-derived and GPL-licensed, all JDK 7 features can be added.

No. Only features that don't infringe additional patents can be added by the community. If Oracle owns patents covering a particular Java 7 feature, but never releases any GPL code implementing that feature, then the OpenJDK community cannot implement that feature.

Releasing code under the GPL does not give the open source community carte blanche access to all your future patents, perhaps unless those patents are necessarily infringed by the original GPL release.

Indeed. The GPL protection only covers OpenJDK as it is released now. However, Oracle would have to tailor the features in JDK 7 as to be under patents they own or licensed, but that are not used in OpenJDK.

And the OpenJDK folks can always implement around those patents.

"After all, before OpenJDK, GCJ and lots of other free Java implementations released fine without TCK."

GCJ is old... and OpenJDK does have access to the TCK IIRC...

> OpenJDK does have access to the TCK

Of course it does, access to the TCK was always at Sun's discretion to give.

OpenJDK doesn't matter, Java is not free to be implemented by open-source projects (even though JSR 270 explicitly says so) because the TCK licensing prohibits it.

It is also irrelevant if GCJ is old, patents don't have a "use it or you'll lose it" clause as trademarks do.

GCJ is old, but is there any other implementation that can compile to native code? (Mainly good for simplifying distribution and better interfacing with native code instead of JNI.)

If I recall correctly, GCJ's `compiling to native code' really means `slapping a bytecode interpreter and your bytecode in the same file, and calling it an executable'.

This is not correct at all. It generates actual native code from Java source files or byte-code.

Excelsior JET... is an AOT compiler...

http://www.excelsior-usa.com/jet.html

It is licensed...

I would also add the question: If I'm running Java on the server to deliver Web services, who cares? It's still open source, I have no plans to distribute MyPersonalVM that can run Java.

Google is the one that wants to keep it's advertisement machine going. It matters to them that over the next few years an open and mobile competitor is around. It doesn't matter to me.

The author pointed out that Sun/Oracle's posture is not resulting in as healthy an ecosystem as other languages with multiple independent free implementations.

"These multiple implementations of the languages are creating innovation on their respective platforms."

He also criticized the JVM.

"not resulting in as healthy an ecosystem"

No ecosystem? Clojure, Lucene/Solr, Cassandra, Groovy, Hadoop to name a few are all part of this excellent ecosystem.

Edit: There's some serious group think in HN. It seems any kind of alternate opinion gets immediately down modded. You may disagree with my opinion, but it is a valid and relevant opinion: Is all this lawsuit crap between the MegaCorps relevant to the average developer using Java for services?

I think he meant an ecosystem of differing implementation. When .NET actually looks more open than your platform, I think you need to rethink what you are doing. What people here are asking for is something similar to Mono, a complete reimplementation of the platform and language that is legally available.

And I agree that java has a large ecosystem built on top of it, making it even more important that the underlying stuff doesn't get controlled by one person.

Funny you mentioned 2 projects under the stewardship of the Apache Foundation, the same organization whom Sun proper fucked by first not releasing the TCK under reasonable terms, and second by releasing OpenJDK under a license incompatible with Harmony and too restrictive to be of any use to mobile phone manufacturers, but not restrictive enough to protect derivate works (GPLv3 was already released and the Apache license has a much stronger patents clause).

Here's some context: http://www.apache.org/jcp/sunopenletter.html

Also, all these language implementations are symptoms of a larger problem, can you guess which?

Yea I can guess, that Java the language sucks.

I'm just saying all these articles about the death or lameness of the JVM are not covering the big picture.

The JVM will be alive and well, but these developments and the fact that the JCP process is a joke are hurting the community a lot.

If the average developer would prefer to develop for Android rather than Java ME, I think it is indeed relevant.

To you it is very relevant. I'm just saying let's clarify who has a dog in this fight.

Believe it or not, I'm using Solr, Groovy and Clojure and in my eyes the (approved || sanctioned || blessed) JVM has never a better platform.

OK, you're a happy Clojure user (I'm not familiar with Groovy and haven't heard of Solr). Clojure is very functional and I expect idiomatic memory usage patterns are different than those of Java and other imperative OO languages.

Oracle's patent lawsuit against the Dalvik VM has cast a cloud on deep innovations in JVMs, such as GC implementations tuned for Clojure.

Is there going to be a long term problem? Who knows, who can say? All we know is that Oracle's lawyers were eager to sue Google whereas "patent suits [were] never in Sun's genetic code" (http://nighthacks.com/roller/jag/entry/the_shit_finally_hits...); what follows will depend on how that goes and who knows what else.

At the very least I'm pretty sure this is having a chilling effect. If you have various areas in which you can do things, why do deep JVM innovation. E.g. for Clojure, perhaps Clojure-in-Clojure targeting another platform, most especially x86_64? (This is not idle speculation, BTW.)

I don't disagree with anything you said.

I'm just saying the sky isn't falling for the average developer that is using the JVM. We'll all be using XYZ technology, which hasn't been invented yet, in 3-5 years anyway.

Google is the one with the short term vested interest in distributing a VM that runs Java.

Google's Dalvik (VM) does not run Java.

The Android _SDK_ is Java based. The Android apps are written in Java, the language, compiled into Java bytecode (Java class files) and the class files are converted into single dex file, which is custom instruction set. Then the app is moved onto the device and run.

The Android runtime is neither Java, nor JVM. It is custom (proprietary) VM that happens to use library that is API compatible with Java's standard library (Apache Harmony compiled and converted to dex; again, no java bytecode in sight).