Oracle wants $9.3B for Google’s use of Java in Android | Hacker News Reader

Oracle wants $9.3B for Google’s use of Java in Android

computerworld.com

132 pointsmiralabs142 comments

I was thoroughly impressed with the judge who presided over the last ruling -- IIRC he went so far as to learn at least the basics of Java to the point where I remember being impressed by the insight of the questions he posed. There are subsets of law one can specialize in ranging from medical malpractice to obscure patent litigation, but as far as I know there are no factors linking a presiding judge to a specific specialty. I really think other judges should follow the example he set and at least develop a core understanding in a similar fashion.

Edit: http://www.cand.uscourts.gov/wha/oraclevgoogle the original Alsup opinion

http://regmedia.co.uk/2014/05/09/oracle_google_appeal_opinio... The appeal opinion -- which, as it stands, rules that programming APIs are in fact copyrightable.

(Also, look at the list of counsel -- heavy hitters, damn.)

  Oracle appeals from the portion of the final judgment entered against it, and Google 
  cross-appeals from the portion of that same judgment entered in favor of Oracle as to
  the rangeCheck code and eight decompiled files. Because we conclude that the declaring
  code and the structure, sequence, and organization of the API packages are entitled
  to copyright protection, we reverse the district court’s copyrightability determination
  with instructions to reinstate the jury’s infringement finding as to the 37 Java
  packages. Because the jury deadlocked on fair use, we remand for further consideration
  of Google’s fair use defense in light of this decision.

"I really think other judges should follow the example he set and at least develop a core understanding in a similar fashion."

Many judges probably do, every day, in lots of technically specialized fields, and we're just not paying attention because we're not experts in those fields, either.

Shouldn't assume our field is so much harder for judges to understand than medical, scientific, and other specialized fields judges need to weigh in on.

Not more difficult per se, but more obfuscated. So much brands, paradigms, domain specific metalanguage. Medicine, physics have some kind of shared, time-tested foundations.

>Medicine, physics have some kind of shared, time-tested foundations.

So do programming languages.

You could argue programming really took off in the 80s, and look at the plethora of languages then that are obsolete. Medicine and physics are more than 100 years old; programming is very new in the grand scheme of things and rapidly changing as it "finds itself." It's not very convincing to assert it has "time-tested foundations."

You mean the various kinds of semantics ? in that case yes, otherwise if it's for framework of the day, stack of the day it's hard to reason and compare anything.

Judge Alsup has a long history of handling technical cases. He's no dummy.

I'm aware. I was making a larger critique w/r/t the justice system especially concerning higher level court decisions and the justices (more likely, their clerks) who draft opinions.

Was pretty sure you were aware.

Things could be worse. This could be decided in East Texas, for instance. That well-known hotbed of technical innovation ... /s

On software like JDK, my feeling (without thinking too much) is that the API is actually the most valuable part and the one that requires true expertise to craft.

When I think of API I think of "here is your interface eBNF"

    (interface)* = (class)* 
    (class) = (method_stub)* | (ivar)* | (class_var)*  |(property}* | {delegate}* | {some_LINQy_constructs}* | {other_stuff_from_NETCLR3.5_onwards}* | ... 
    .

"Alright, now implement IEnumerator OnNext(); bool MoveNext(); IDisposible Dispose();"[1] and your data now has the trait/type-class/whatever of IEnumerable! That's all an API is really -- method signatures and code contracts between the requester/requestee. The real gold isn't in that, but in the implementation details of the JVM (and the greybeards who know the -Xxs256 -Xmm10230 blah blah, I suppose.)

I.e. Azul ZING(tm) and the lot of insanely high-performance and/or hard-real-time-in-the-QNX-sense is priced at... a lot. In finance we used to use it because operations could be bounded deterministically. There was enough value in that that CTOs cut 7 figure checks to run that specific API implementation rather than use the Sun/Oracle JVM.

[1] Yep that's probably gobblydygook. My C# and Java meld together, I always confuse IEnumerable,IEnumerator,IDispose,and all the damn duals smash together in my mind, even worse now with Rx one more tensor rank was added (Time). Gods of the CoreCLR, smite me not. Also I'm not in PL design, forgive my bad BNF.

Why do you think so?

The java.* API is not even that good (it is very verbose to achieve basic things). The only reason to re-implement it is compatibility with existing, third-party software using that API.

If you would come with API, that would be technically better, but doing the same thing, do you think that everyone would rewrite all their libraries, frameworks and apps? No way.

That's the point. The API isn't valuable because of the creative expression (the thing copyright protects), it's valuable because its functionality (the thing copyright doesn't protect) is necessary for compatibility.

Oracle apparently bamboozled the Federal Circuit into deciding that something called the "structure, sequence and organization" of the API should be copyrightable. But of course nobody cares about that part -- the order doesn't matter. You can sort the API into alphabetical order and strip out all the comments and it would make no real difference to anybody. But here is Oracle claiming that the copyrightable part is worth billions of dollars.

If copying the APIs is only valuable for compatibility, why did Google do it? Android isn't compatible with any Java apps.

It's compatible with many Java libraries and IDEs etc. It isn't compatible with Java apps because the UI framework has to be different on a phone. Porting Java apps thereby requires changing only a minority of things rather than everything.

It's like asking why you can write C programs on Windows even though it doesn't provide an X server.

Libraries, though.

Java Map interface specifies: V get(Object key) I was horrified when I realized you could pass any object to get()

interface{}

FYI, Oracle is pushing this agenda to squeeze Java shops in other places as well.

The tack they are taking is to define any computer that does "one specific thing" as an embedded device and ask you for $300+ per "device", plus some other lofty fees. (http://www.oracle.com/us/corporate/pricing/price-lists/java-...)

So, if you're using Java in a kiosk, ATM, media player, etc, they may be coming for you.

My guess is that this just spawns a mass migration to OpenJDK, but perhaps they trap enough Java shops that it's worth the effort?

My guess is this just spawns a mass migration away from Java altogether.

Not knowing when Oracle might decide to shake down your business is a massive incentive to use anything else.

Didn't I recently hear something about Google rebuilding Android to remove Java? Or am I totally off?

I think they said they were moving to OpenJDK for Android.

That would likely cost much more than this extortion, and still wouldn't save them.

First, I don't see any way that moving to OpenJDK is going to cost more than $10 billion. Second, if I understand correctly, OpenJDK has a license grant from Oracle. That's going to make it really hard for Oracle to say that Google doesn't have permission to use it.

Moving to OpenJDK might not, but does not retroactively ameliorate any issues they had.

I also suspect that OpenJDK's license might bite them in problematic ways, or they would have either done that to start or not had such difficulty negotiating an agreement under whatever terms Java possessed that Google might have wanted alternatives for.

> Moving to OpenJDK ... does not retroactively ameliorate any issues they had.

True. It does prevent damages going forward, however, and it removes Oracle's biggest club - a court order forbidding any further shipments of Android.

More than 9 billion? Give 36,000 people $250,000 a year salary and you still haven't hit 9.2 billion. Pretty sure they could get it done in a year with 36,000 people.

37 women cannot have one baby in one week.

The only thing better than throwing more engineers at an already-late solution is hiring a mass swarm of engineers and turning them loose on a only-semi-bounded new problem.

Why wouldn't it?

How is this any difference than installing Windows 10 on your Kiosk? You are paying for updates and support. You are free to use Linux and OpenJDK if you don't want to pay. Most shops I know of are using OpenJDK for all production deployments at this point unless you have a larger contract with Oracle.

It would be similar if Windows originally released with a license that let you use it without charge, and then later changed the terms of the license in an obscure way that classified a full sized PC as an embedded device.

Since Windows has been clear from the start that any commercial use requires a paid license, it's not similar in any way at all.

Kiosk licensing has always been required for shipping machines pre-installed with java. Sun required this 10+ years ago as well.

I'm not a lawyer but I believe this what you can do that you can't do with windows is ship the kiosk without java but give the customer a CD-ROM to install it themselves.

Reminds me of the good burghers of SCO and that little shitty they tried to pull off in the beginning of the century.

It didn't end well.

Sure it did. Linux.

Both the Linux kernel and the GNU OS predate Caldera acquiring the Santa Cruz Operation and turning into a lawsuit house.

But SCO preceeded Linux. If there'd been a cheap version of SCO in the first half of the 1990s, I doubt I'd have looked twice at Linux. My employer at the time did look at SCO, but WFWG solved the problem for us.

But your sequencing is dead on. It's a messy story.

Ah. I think the original commenter was referring to the lawsuits, not to SCO's business model when it actually had products and services.

How would this affect me if i'm using Tomcat to run something like Solr? Am I suddenly on the hook to pay Oracle, even if I am using OpenJDK?

OJDK is GPL v2, so you're a-okay there unless you're shipping a binary (in which case, upon customer request, the source + derivative code has to be released). RH puts out a "100% free" version under the moniker 'Iced Tea', if you want to play it safe. Realistically, attorneys are expensive -- going after a startup worth maybe 10MM on paper for a license violation isn't an economically prudent move for anyone.

OJDK is GPL, but with the "Classpath Exception", which makes a big difference.

http://openjdk.java.net/legal/gplv2+ce.html

will this affect jvm languages as well?

I don't think there is a lot of embedded Java left.

Oracle should pay Google for using Java in Android and keeping the language somewhere around edge of hip and cool. I wonder how long it will be before Google flips to Go or JavaScript for Android.

It will never happen.

In spite all of this, Android Team has given zero support for anything other than Java on Android, even for its own languages.

The NDK is anemic, because "In general, you should only use the NDK if it is essential to your app—never because you simply prefer to program in C/C++. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need."

http://developer.android.com/tools/sdk/ndk/index.html

And the Go and Dart teams had to work on their own even for the NDK integration.

The results of their work aren't even described in any of the official Android documentation sites.

Never say never, that's what I thought about Apple and objective-C, and they just invented a new language for it.

True, it runs in the same runtime, but it does allow them to slowly move away from 20 years of history. Mind you, the obj-C runtime / Foundation isn't badly set up at all, I'd argue it's better than the Java SDK.

As the one that raised the Go support ticket for Android, back when I was still following Go I doubt it.

That ticket was raised before Go 1.0, so I very much doubt it.

Go and Java stdlib have very different opinions about the basic types, used by every app (like strings or maps, heck, even about concepts what is a class and class hierarchies, or how the stack is supposed to look like).

So unless you want to wage a perpetual war at the border between your app and Android base libraries, forget Go, or about any language that does not run on JVM.

Without providing close to 100% interoperability, replacing Java with another language would be insane. All the open-source third party libraries for Android (and there's plenty, and many of them have become the de facto industry standard), all of that goes out of the window. I don't see how it could pan out

You make something that's easy for an automatic translation. Then you use that. It's how both AS/400 and OpenVMS kept binary compatibility on completely different hardware over time. The good news is there's a lot of clones of Java in CompSci and compilers of other languages targeted to JRE. Retargeting them to something similar wouldn't be hard. Recompiling bytecodes wouldn't be hard.

It's the high-level language and interfaces that would be hard. The real factor, though, is social given lock-in is in full effect here. Java was a bad, long-term bet given the Oracle acquisition.

So progress should be avoided if it means throwing away everything else?

I can see Android rolling this out across two major releases. The first adding support for a new VM or app language and the second removing Java. Time between those releases will give developers the chance to catch up.

I just think it's silly that you are opposed to throwing everything away. That is what got us in this mess to begin with. Android was supposed to be a simple transition for existing J2ME devs.

Ditching rich pre-existing ecosystem by itself certainly isn't progress. The greatest language without that ecosystem is like the shiniest OS with no apps. This includes communities, developers who've acquired enormous amounts of know-how by now... It would be extremely hard make this trade-off worth it. A tough call, and a multibillion dolar company will think more than twice before choosing that route. I know I would

"I just think it's silly that you are opposed to throwing everything away"

That may be, but I'm pretty sure Google wouldn't think so :)

It took Apple 12 years to deprecate Carbon API. It is still being shipped for compatibility.

Nobody really throws away anything, that other people are depending on. Especially, if you are depending on their continued investment into your platform.

Otherwise, Windows Mobile to Windows Phone happens. Or Python2 to Python3 (how many years it is already taking?)

So two major releases is too optimistic. Especially in android world, where more than two major releases are used simultaneously.

If that is the level we are happy about you can already run with Kotlin today. Its not official Alphabet, but it is offical from the company that makes Android Studio and it is roughly to Java what Apples new language was to Objective-C.

Unfortunately that still means that there is no good way to write cross-platform mobile apps.

There is never a good way to write cross-platform apps. Cross-platform programs are always inferior to solutions specifically designed for a particular use case (e.g. touch input + mobile device, pen input + tablet device).

I agree there needs to be a platform specific input output layer, but assuming you are writing the same app on different devices there is always going to be a large core (essentially all the business logic, all models, all validation, all sync code) that is, or should be, the same on all platforms. It is that code I wanted to refer to.

Yeah, unless there's explicit orders from above I don't see them moving (and usually Java people like to live in Java world and ignores everything else)

Google should have started looking at alternatives back them and making another environment first-class on Android as well

(or maybe they can just compile Go to Dalvik and flip the switch, I don't know)

I don't think anyone has used "hip and cool" and "Java" in the same sentence for at least 15 years (2001) and no amount of Android can fix that.

"Damn, that grotesque-looking android startled me and I spilled my cup of Java all over my hip, fortunately it was cool so I didn't get burnt".

This reminds me of that contest where people had to get the phrase "I smoke crack rocks" into a published academic paper, and the winner was something like "we burnt iodine (I) solution to observe its corrosive effect on stone and witnessed I smoke crack rocks".

Kotlin? :) --> https://kotlinlang.org/

...which uses the Java API and libs... It's a more pleasant option than Java but it's not going to solve the API copyright issues.

Java devs talking to me about Groovy always made me chuckle

Groovy has to be one of the most cringe-worthy names in the history of programming languages.

Right ? If they keep putting Google under fire for the use of Java, they will only accelerate the process of Google moving away from Java (which is a huge task mind you) and as a result Java will loose a lot of relevance.

Google have indicated a future Android-Chrome merger. Although the public announcements were to the effect of Android simply replacing Chrome, there has been speculation about other outcomes. Perhaps this suit will encourage movement in the other direction, from Android to Chrome.

They did a proof-of-concept Dart runtime (Sky/Flutter).

The bad news was, that everything was reimplemented in Dart, including the widgets, so they had that not-quite-native feel.

I'd say never. That would kind of be like an apple switching to Swift for iOS.

This is even harder for the Android runtime because it's run on a virtual machine with characteristics that don't easily map to another language.

Basically if they switch to any other language all the apps that currently use Java (ie. all of them) will have to practically use their own VM -which would be slow - or reprogram everything in another language - which would be expensive.

Actually as a first step the language could be implemented on top of the dalvik vm. It's just that the IR of go would need to change for that target. Something like Truffle for OpenJDK could help by adopting new languages.

That takes care of the language but none of the API's. I suppose that would be the second step.

It sounds like this all would take a lot of time to complete. What would be the point for Google to do all this work?

Why would maintaining two runtime make dalvik app slower? They're all interpreted anyway.

I was talking about the developer supplying their own VM on top of whatever the new runtime is going to be.

However I suppose they could just add an extra one on the side. I wouldn't really consider that switching though.

They were JIT-ed for a while. That's what the "optimizing apps" modal dialog after updates is about.

>They were JIT-ed for a while. That's what the "optimizing apps" modal dialog after updates is about

I think you meant AOT-ed. The language really doesn't matter though, as long as it can be converted to Dalvik bytecode.

Yes, AOT-ed :)

I don't see Android team itself is going to switch to Go or Javascript for android. Otherwise, I would say Kotlin[0] would be a better alternative to Java.

[0]: https://kotlinlang.org

Few things comes to my mind:

Kotlin is JVM + Java interoperable language and this is its major if not sole selling point. So it does not help Google in any way regarding Oracle-Google copyright and patent issues.

Any kind of support might come when some developers get down and write lot of code to support that language. Android team is not going to add any support just because someone wanted or voted to support new language on Android platform.

At least people who wanted Go on android have written extensive amount of code to add support and still they are far from done.

I'm curious how switching to Kotlin would help since it relies on the Java APIs and libs...

Kotlin is hip and cool.

Since it outputs bytecode, IANAL but it probably does not helps with Java APIs litigation.

Javascript? I hope never.

Will miss groklaw badly. Followed the previous time almost entirely on groklaw.

What is Pamela Jones doing nowadays? I understand her decision to shutdown groklaw because of govt spying but I can't help but think that, overall, it was a net loss for everyone involved.

Yeah. Government spying is like that.

I miss PJ and Groklaw, too.

Google should have acquired Sun instead of buying dropcam/boston-dynamics/motorola and such.

How amazing would that have been? Zfs might have helped the world move forward a lot faster... Sigh...

Let's give Oracle 10 years from now to fade from relevance as yet another fucked by cloud vendor and Google can then orchestrate a hostile takeover.

To speed that up, just buy Postgresql and use that to smother both Oracle DB and to some extent, mysql. Defence only helps that much, offence can do it a lot faster on their own DB territory.

Better yet, buy EnterpriseDB that's actively targeting Oracle's market. Put a bunch of money into expanding it with conversion tools from Oracle to not Oracle API's it will use.

Given how much Google owed Sun in terms of technology and employees pulled from Sun over the years, I always thought not buying the company was an especially cynical move. Sort of like, "Ha! We got all their stuff for free and now they're gone! We win!" Payback's a bitch - though in this case it's not just going to be Google that pays. Oracle is vicious.

Dart is a very viable alternative to Java already for Android. See https://flutter.io/

P.S. Dart actually has a Java-to-Dart converter hidden somewhere. I can't find the link, but the static analyzer was ported from Java to Dart using it. Perhaps they could expand that effort?

This case seems unusual in the fact that the code in question was already free to use and fork under the terms of OpenJDK, so paying Oracle for a license was not the only alternative. How would one calculate damages relative to the scenario where Google simply used OpenJDK as they are doing now?

Maybe Google is doing things that the "Classpath Exception" doesn't cover, which would expose them to parts of of the GPL that don't work for them?

Oracle has a legal department twice the size of its developing department

:-)

C# is such a nice language, and Microsoft has been making such strides toward openness and cross-platform with .NET lately.

Imagine if Microsoft granted Google a perpetual license to use C#.

And Google briefly considered adopting C# instead of Java back in the day. As a .NET dev turned Android dev (and not liking Java 6 one bit) I regret they didn't go down that path...

http://www.wired.com/2012/04/android-google-oracle/

In another 2005 e-mail admitted as evidence by Oracle, Rubin tells Google co-founder Larry Page: “If Sun doesn’t want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language, or 2) Do Java anyway and defend our decision, perhaps making enemies along the way.”

Let's not forget that Microsoft is backing Oracle in making API's copyrightable.

http://arstechnica.com/tech-policy/2013/02/microsoft-foresee...

They're already working with MIT and a patent release.

https://github.com/dotnet/coreclr/blob/master/LICENSE.TXT

https://github.com/dotnet/coreclr/blob/master/PATENTS.TXT

Brainfuck probably has an equal chance of being selected as C#. The problem is more that the APIs and all of the existing apps. Google can't just wake up one morning and decide that everything will be now in language XYZ because there are literally millions of apps for Android which have been written in Java against Java APIs. C# would also be an unusual choice for a company that does zero(?) C# work.

Now it's too late, but unlike Brainfuck, Google did consider C# as an option, see my comment (sibling comment to yours)

I don't know. Weirder things have happened. And we're talking about a decision with billion-dollar ramifications.

http://techcrunch.com/2015/03/05/microsoft-and-google-collab...

I think replacement of Java in Android is coming slowly and likely without any help from Android team.

Looking at gomobile and CLs on golang-dev etc I feel Go support in Android is worked on by small focussed team rather than order from top management.

If this teaches us anything, is that you should avoid as hard as you can, giving others rope, with which they can hang you. I avoid Java anywhere I can, so for me, Java is only for mobile apps on Android.

I also invite anyone reading this comment, to read the following story, which always comes to my mind in this sort of events: http://www.folklore.org/StoryView.py?story=MacBasic.txt

That's the same amount they had thrown at Sun Microsystems.

actually a bit more since Sun cost Oracle about $7.4B.

I can't see this ending well for Oracle.

1. Oracle's lawyers are idiots as they can't show it's same. For example run apache http client jar on android and java. It's same. Idiots.

2. If Oracle's dumb lawyers win, I'm happy. I get paid a salary to work. Why should companies get code for free, why do they need me. Copying and violating a license is bad. Even GPL and other code I write, respect the license.

3. To summarize, would you want Google to violate GPL?

I really don't understand what Oracle's lawyers are thinking.

Yes, coming up with ever-more-creative theories about why Google owes Oracle might have some tactical advantages, but any victory in court on those terms would be pyrrhic.

It doesn't matter how many billions Google coughs up if the next phone call is IBM demanding the company for using SQL.

Aren't Oracle's lawyers looking past the next move? Are they that confident that their API arguments will lose? Do they really have that much faith in the hairs they're splitting between Google's API reuse and Oracle's?

Or is their advice being colored by all the follow-on legal work there will be because Oracle is going down this path?

That might be legal but in my opinion not ethical.

I just wished google would use C++ for Android. It's does away with all this nonsense. I'm looking forward to the day where I have to pay oracle for every android app download I get even if the app is free...

Recently: https://news.ycombinator.com/item?id=11376439

Could someone with a legal background please explain what Oracle would have to prove to win this?

Disclaimer: I don't have a legal background.

If I understand correctly, Oracle would have to prove that Google's use of the Java API did not fall under the fair use exception in copyright law.

That is, if I write something, you can't publish it as your own. That's copyright. But there are exceptions within the law. One exception is fair use (others are criticism, parody, and there may be more, but fair use is the one in play in this case). Note that fair use was in the original trial, and the jury deadlocked on whether that was a valid defense for Google.

Below here, my understanding is less solid. But I think that one category of fair use is interoperability. That is, if I have a copyright interface (like, say, an API), you can copy that API in order to interface to something. To what degree, and what the boundaries are, I'm not sure.

Kotlin in Android looks promising.

Kotlin relies on the Java APIs and libs, so wouldn't really help.

What's the argument that Google should pay Oracle? Is there something in the Java license?

Has Google's use of Java somehow damaged Oracle? Are they worse off now than they would be if Android were built on a different technology?

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

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

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.

[1] http://developer.android.com/guide/index.html [2] https://source.android.com/source/jack.html [3] http://developer.android.com/reference/java/lang/package-sum...

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.

I think you're conflating Java the language and the Java Virtual Machine. Android does not run the JVM, it runs Dalvik and now ART. Android is going to continue to do this. But it has and will continue to use Java the language, not some language based off Java, as well.

And in fact Oracle's lawsuit is about neither the language or the runtime, it's about the APIs. Yes, they were taken from Apache Harmony. Oracle insists that Android's use of them infringes because Google created a derived work, incompatible with the full Java API, from the Harmony implementation of the Java API. Google, in fact, is replacing the Harmony code with OpenJDK[1], Oracle's official open-source implementation of the Java API. (Which is one of about a billion reasons why your claim that Android uses a language based on Java instead of actually using Java is so baffling -- it's so based on Java that they can replace their code with Oracle's official Java implementation!)

[1] http://arstechnica.com/tech-policy/2016/01/android-n-switche...

>But it has and will continue to use Java the language, not some language based off Java, as well.

Java is not the syntax, though, it's the whole specificication -- down to the bytecode.

Google just borrowed the syntax (and API).

(As did other people and projects who did "clean room" clones of Java, while not calling their product/project Java).

>And in fact Oracle's lawsuit is about neither the language or the runtime, it's about the APIs.

Yeah, that's what I wrote above: "That's just at the superficial API level though, which Oracle contested in court".

I mean, up until a year or two ago, Google just shipped Oracle's javac compiler with its Android build toolchain. This makes about as much sense as saying that if you use musl libc instead of glibc that you're using a different language.

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.

Yet another reason I push updating the old Modula, Oberon, or Component Pascal languages instead of using C# or Java. Both are controlled by scheming, money-hungry companies that try to eliminate competition and innovation outside their firms. Best not to be tied to such companies at all.

How the number $9.3 billion is derived?

Reported earnings from Android, one would guess.. though as Google mentions, this is likely ALL they've earned from Android as a platform, nut just the impact of those specific methods.

Reply on news.ycombinator.com