J++ got into trouble for trademark issues because MS called their incompatible implementation Java(TM) and caused brand confusion. Android does not do this.
But Google doesn't call its fork Java(TM), which makes all the difference between this case and J++. The practice of independently implementing and modifying an API has never been questioned until now. It was not in dispute in J++ and it's in fact the reason why software projects like GNU/Linux (which is at most an approximation of AT&T Unix and has never received any sort of certification) are able to exist.
>I cannot take whatever piece of Java code I feel like it and run it on Android.
And you weren't meant to.
It's a whole different environment, and they made their own language for it, which they happened to base on Java.
The didn't call it "Java", nor they targeted regular Java deployments (like MS did).
They just wanted to have something that looks familiar to lots of devs, but for THEIR platform.
If MS had done the same (and in fact they sort of did, as early C# was heavily based on Java -- just not as much as Google's) they'd have no issue with SUN. But instead they did those changes while still calling it Java and offering it for Java development on Windows.
(Besides, "I cannot take whatever piece of Java code I feel like it and run it on Android" was also true for SUN's own Java Mobile Edition too, when it comes to the mobile edition's compatibility with the Java SDK's on the desktop/server).
What on Earth are you talking about? From Google's own developer reference[1]:
> Android provides a rich application framework that allows you to build innovative apps and games for mobile devices in a Java language environment.
In order to compile for Android, you use JACK, the Java Android Compiler Kit.[2] I could go on. Google uses the name Java all the time in reference to the language used for Android.
Google didn't base a language off Java. Android uses Java-the-language, unmodified (and an outdated one at that). It uses some existing Java APIs as well, and keeps the same names, which is why the official Android API reference[3] has the word Java appearing more times in it than a history of Indonesia.
That's because, as they explicitly write: "Android follows the package and class namespace conventions defined by the Java programming language". And obviously, the names in the packages are carried over, including sun.*, and the documentation is gonna follow that -- though the official name of the runtime is Dalvik (and ART), not Java or JVM or anything like that.
As I wrote, that was intentional, so that it's immediately familiar to Java programmers. That's just at the superficial API level though, which Oracle contested in court and I don't recall HNers being on their side...
Nobody was ever meant to use it to replace Java in their Java deployments and enterprise apps, or to run Java apps as is on that environment. And Google never promoted it as such -- as a Java replacement. Only as a Java-like environment specifically for Android development, and tied to the specific needs of its OS and devices.
What Android actually runs is a different language implementation through and through, with a different scope (target OS, environments, use etc) and a different VM, GC and tons of different APIs, with tons of not used APIs compared to the Java one's too (Swing for starters). And it's own bytecode of course.
So why should it follow Oracle's Java versions and progress, when it's NOT meant as a Java replacement? It has its own roadmap.
Heck, even the Java-like code behind the APIs, what's not 100% Googles, is not Oracle's or Sun's, but from the open source Apache Harmony project.
They never claimed their implementation to be Java compatible, and there is no legal precedent entitling one to demand all implementations of a library to be compatible even when they do not claim compatibility. GNU/Linux certainly has never paid to be Unix(TM) certified, and despite SCO's repeated legal assaults, the API itself was never in dispute.