Hacker News new | ask | show | jobs
by signa11 3734 days ago
afaik, the real issue is that the dalvik-vm is api compatible with oracle(sun)-jvm. iirc, api is not 'copyrightable' which seems to suggest that it might not be so good for oracle. but then again, cases like these depend a lot on proficiency of presiding judges. wasn't there an earlier judge, who learned some elementary programming while preparing for this case, and who ended up favoring google...
1 comments

If it were api compatible Java Android wouldn't be the second coming of J++, where apparently thanks to some strange events it is ok for Google to fork Java, break WORA where even many Java 6 libraries cannot run on Android, not to mention about later versions, and some devs seem to think it is ok.

While with Microsoft everyone went out with their pitchforks.

Android Java is nothing more than Google's J++.

To refresh your memory: "The complaint charges Microsoft with trademark infringement, false advertising, breach of contract, unfair competition, interference with prospective economic advantage, and inducing breach of contract."[1]

You probably know this, but Java-the-language is not the same as Java-the-platform (VM); Google only uses the language bit, not the runtime. They created their own runtime (Dalvik, and later ART) with its own bytecode format. What Microsoft did was implement an intentionally-incompatible JVM, hopefully you see the differences between Google and Microsoft's action (both technical and the reasoning behind the actions)

Edit: changed quote from wikipedia to [1], added reference.

1.http://www.javaworld.com/article/2077055/soa/what-does-sun-s...

I know pretty much what happened.

The fact is that Google forked all of it.

You cannot use anything besides a pseudo Java 6.5 (the language), because there isn't support for all features available.

You cannot make use of the full Java SDK libraries, because Google's fork only supports cherry picked portions of the JDK, to the point that people have ported JDK classes to Android to close the gaps when porting Java code.

You cannot rely JVM features, because Dalvik/ART don't support everything that it is possible in a certified JVM like invokedynamic or more updated JNI versions.

The fact is that Google broke the Java eco-system, regardless how Google fanboys want to paint the picture that Google != Microsoft.

They tried to screw Sun and take advantage of their economic misfortune.

Luckily I don't suffer from Google colored glasses.

Reality tends to have more nuance than you are willing to admit in this instance. Sun v. Microsoft was over very specific issues.

Even thought the specifics don't seem to matter to you, I'll add a bit more detail. "The sticking point is that Microsoft decided the Core Java class libraries were insufficient for its needs. Now there's nothing wrong with extending things by subclassing and placing the new objects in a package outside of the java.* class hierarchy. But deciding to add about 50 methods and 50 fields into the classes within the java.awt, java.lang, and java.io packages, as Microsoft did, is extremely problematic. "Microsoft deceptively altered key classes and inserted them into their SDK," said Baratz, which results in developers thinking they are writing Java, when actually they are writing something that runs only on Internet Explorer.[1]

> They tried to screw Sun and take advantage of their economic misfortune.

I have some sympathy for Sun, but had Google asked for permission for Java on Mobile, Sun would have insisted on the abomination that was J2ME because that was their mobile strategy. I'll take Java 6.5 over J2ME any day

1. http://www.javaworld.com/article/2077055/soa/what-does-sun-s...

No Google "fanboy" (I actually hate the term, it's for immature 20 somethings to use), but Google didn't break the Java ecosystem IMHO.

The created a whole new language that happens to be mostly based on Java, for a very specific target OS where Java wasn't even available before.

The familiarity with Java is merely a bonus and boost for the adoption of Android programming from Java devs. It's wasn't meant (and it isn't) a jab at taking the Java development market (which is was Microsoft did -- going after the same people using Sun's Java, and for the same environments they used it in).

> The created a whole new language that happens to be mostly based on Java

That's the "extend" part of "embrace, extend, extinguish."

Not in the old MS-SUN wars sense.

Extend implies extending an existing X product.

Google made their own runtime, NOT calling it X, and NOT targeting the same platforms where Java was available. And of course this never had any impact on regular Java itself -- so no extinguish part. Nobody stopped using Java on the server or the client even, to use Google's version, because it's not offered at all there.

Their language not only didn't target existing Java deployments, but it was also created (and has always been constrained) for a new platform where Java never existed, and for a usage domain where Java had negligible presence (mobile development in post-iPhone smartphones).

And even if they HAD targeted normal Java deployments, it would have been totally find, and not "embrace, extend, extinguish" if it wasn't called Java. It would have been like MS' C#, not MS' altered Java.

If you don't pretend it's the same product (like MS did), then "embrace, extend, extinguish" is exactly how evolution works in most cases, including the natural one -- things get replicated and some crucial extra sauce is added, and if it's good, then the old things wither.

In fact, in this sense (where you mimic another opponent) "embrace, extend, extinguish" is exactly what projects like OpenOffice, Gnumeric, Gimp, etc intended to do.

But, as said above, this, while also fine, is totally different to what Google did.

Google never claimed that Android runs Java (after all, it does not, dex is not Java Bytecode and Dalvik/libART are not JVM). It never passed TCK and never claimed to.

They claimed that you can write Android apps in Java language, or reuse your existing libraries written in Java - like Google themselves did with Apache Commons.

On the contrary, J++ claimed to be Java implementation.

If APIs are going to be copyrightable, it will allow Oracle to hold all the third-parties using Java (or another JVM-based, like Kotlin or Scala) language hostage wrt where they can run their own software.

The end result is the same in terms of broken eco-system, anything is just word games.
J++ got into trouble for trademark issues because MS called their incompatible implementation Java(TM) and caused brand confusion. Android does not do this.
The fact is that Google forked Java, there is no difference at all.
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.
The fact is that they borked Java compatibility story, regardless how their supporters sell the story.

I cannot take whatever piece of Java code I feel like it and run it on Android.

>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).

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.
Only where "forking" or not forking is concerned.

But there are tons of differences in other aspects of the issue -- which make all the difference as to the MS case.