I wish intent and end result counted more strongly. Andoid's compatibility isn't transitive: once code goes through the Android build pipeline to produce an Android Application it cannot be meaningfully used in the context of Oracle Java; it's a one-way transformation to remain "talent-compatible" with a large pool of Java developers and reuse the base of Java libraries.
Projects like OpenJDK and WINE are efforts to provide an alternate execution environment for code that is mutually beneficial to the ecosystem, although perhaps not the wallets of the original owner. A commercial venture ought to qualify here if the intent is to compete on equal footing -- code targeting OpenJDK can run unmodified on Oracle Java, code targeting WINE can run unmodified on Win32, thereby not limiting the original creator's rights.
However, Android Apps contain unrelated public APIs as part of the exported code, and a full packaged Android App cannot meaningfully run on Oracle JDK, despite portions of the standard library looking and behaving alike. This fragments the ecosystem and essentially allows Android to benefit from the works of the Java rightholders without making those contributions equally as useful to Oracle Java itself.
once code goes through the Android build pipeline to produce an Android Application it cannot be meaningfully used in the context of Oracle Java
Android apps typically have an MVC-like structure where the UI uses Android-specific APIs, but the model is straight Java. As an example, I created an Android game and later decided that I wanted to make a level editor as a desktop Java application. I was able to reuse the model code in Oracle's JDK with no changes, even though I didn't have that use in mind when I originally wrote it.
a full packaged Android App cannot meaningfully run on Oracle JDK
Right: and if you remember, the entire concept of a "platform-specific Java API" is what was at stake when Microsoft lost this very similar lawsuit when Sun sued them over J++. Either what Google is doing is horrible or what Microsoft did shouldn't have been a problem :/.
> Either what Google is doing is horrible or what Microsoft did shouldn't have been a problem
Maybe go reread about the case? It was basically breach of contract and thus quite different.
The basis of Sun's lawsuit was that Microsoft had a license to implement Java™ and part of that license was the requirement that their version would be compatible as defined by the compatibility test suite.
In their attempt to "kill cross-platform Java" they failed to be compatible and so Sun sued and won.
Huh! So, there were multiple rounds of lawsuits, and I will admit I missed this (very important) detail of the part that Microsoft actually lost. I think it is still important to note, however, that the main reason any of these companies actually ended up in contracts with Sun was due to Sun's claims to ownership over the language standard itself, and there is some really great phrasing about Sun's feelings on this in this contemporary article from the Wall Street Journal. But again: you are absolutely right about what is different, and I am sorry for not noticing this before :(.
The issue was the trademarks, which exist to prevent consumer confusion. J++ would have been allowed to exist, but it had no right to use the trademarked "Java" name, because if it only runs on MS it's not "Java".
Except that all of the Android code is open source and you could port its runtime or API to any platform you like.
The argument you're making is that Oracle is the only party who should be able to extend Java, despite their also releasing it under an open source license. Which, if they hadn't done, no one would have used it to begin with -- as seems to be the direction things are headed given their recent behavior.
> This fragments the ecosystem and essentially allows Android to benefit from the works of the Java rightholders without making those contributions equally as useful to Oracle Java itself.
Java SE, Java EE and JavaME are incompatible. Java was already fragmented by their creators
Hell, JavaME wasn't compatible with JavaME, depending on which vendor versions you were comparing. Sony Ericsson had classes totally different from Samsung or Nokia. Add CLDC versions and varying CPU and memory capabilities to that toxic hellstew to effectively kill the WORA dream.
Sun/Oracle can't blame Google for their abysmal mobile strategy.
I can attest to this, and wrote a validation package to detect the differences among Java ME implementations back when I was doing mobile search apps for Java ME devices. A particularly annoying irony is that if you tried to use the supposedly standard ME UI classes, that's where most of the poorly spec'ed behavior lived, which is what all those vendors pointed to to justify doing their own UI classes. Never mind the intentionally loose specs for things like threading behavior.
Re "This fragments the ecosystem and essentially allows Android to benefit from the works of the Java rightholders without making those contributions equally as useful"
Not based on licensing. There is no licensing barrier to making an runtime with the same semantics as ART or Dalvik that runs Java bytecode and is fully compatible with Oracle Java.
Also not by intent. Dalvik bytecode was designed for running without a JIT compiler in a battery powered device - a very specialized and critical design goal.
Oracle is the party that's playing games with standards and licensing, intentionally keeping openness and licensing requirements opaque and intentionally vague. I know this firsthand.
Projects like OpenJDK and WINE are efforts to provide an alternate execution environment for code that is mutually beneficial to the ecosystem, although perhaps not the wallets of the original owner. A commercial venture ought to qualify here if the intent is to compete on equal footing -- code targeting OpenJDK can run unmodified on Oracle Java, code targeting WINE can run unmodified on Win32, thereby not limiting the original creator's rights.
However, Android Apps contain unrelated public APIs as part of the exported code, and a full packaged Android App cannot meaningfully run on Oracle JDK, despite portions of the standard library looking and behaving alike. This fragments the ecosystem and essentially allows Android to benefit from the works of the Java rightholders without making those contributions equally as useful to Oracle Java itself.