Hacker News new | past | comments | ask | show | jobs | submit login
Google confirms next Android won’t implement Oracle's proprietary Java APIs (venturebeat.com)
256 points by ingve on Dec 29, 2015 | hide | past | web | favorite | 184 comments

What does this mean for OpenJDK? Will Google now be working on it and improving it?

From what I gathered in the previous discussion, it's not a drop-in replacement - they made several changes to OpenJDK already.

Yes, Google's statement in the article suggests Google will be working on OpenJDK, at least more than they already have been.

So, what's the most evil Oracle can be against future versions of Android given this?

And who actually guides the Java roadmap? The OpenJDK trademark grant (http://openjdk.java.net/legal/openjdk-trademark-notice.html) seems to spin on whether or not "the Software is a substantially complete implementation of the OpenJDK development kit or runtime environment source code retrieved from a single Website, and the vast majority of the Software code is identical to that upstream Original Software"?

What's to stop Oracle from deciding that future Java roadmaps are going to exclude Android-specific commits? Neither IBM nor Apple's interests seem particularly aligned with Google here (I'm assuming they throw some kind of weight in the OpenJDK politics).

Time and time again we see such short term thinking does not pay off. It wouldn't be evil on Oracle's part to do that, it would be just plain stupid. The resurgence of Microsoft shows that being open and transparent is the actual winning strategy. Goodwill among developers is not a quantifiable thing but it makes a huge difference.

Yeah, but this is Oracle we're talking about. They do evil and stupid before breakfast and short-term thinking for the rest of the day.

The story I heard was that Larry Ellison was driving his sports car down 101, when a cop tried to pull him over for speeding, so he called ahead to Oracle security and had them stop the perusing cops at the security gate when they tried to follow him into the Oracle compound.

Too bad the ATF and Attorney General Janet Reno didn't take charge of the situation.

I find that story challenging to believe. Fleeing an officer would be probable cause for an officer to enter the property to make an arrest. I can't count the number of times I saw it on Cops (when I worked at a TV station that aired the show)...someone fleeing from a minor traffic violation goes into their home, police follow and make a dramatic arrest. It's not like playing "tag"; there is no "base" that protects you from being tagged by police in pursuit.

You could try escaping to an area where they don't have jurisdiction. "Run a red light? Drive to Canada!"

Funny you say that! This was a problem with drug smuggling. Now they have the shiprider program [0]. Basically a Canadian patrol boat has 1 american officer on it to make arrests if it crosses a border, and vice versa.

[0] http://www.rcmp-grc.gc.ca/ibet-eipf/shiprider-eng.htm

If I ever make a driving game... This will be in it.

I just love the absurdity of running a red light somewhere like California, Texas or Florida, then just going "F*&( it, TO CANADA!!!!!" <sound of engine revving up as driver floors it>

I bet OJ Simpson wishes he had his own private police force, a well defended secure compound, and a world class legal department on retainer and speed dial, like Larry Ellison does.

Let's be grown ups here. Oracle isn't evil by any normal definition of the word.

And you sure as hell don't get to $10 billion a year in profits by being stupid.

I don't think you deserve a down vote for being factually correct -- though a little hyperbole ain't gonna kill you. :)

But ORCL has gone from being an innovator to a rentier, and they're not averse to using hardball tactics on top of their historical position to try and stay relevant. Not using that HCM suite? Okay, but before you jump to a competitor just know that we'll increase your licensing fees if you stop using any of our products. Oracle is losing ground when it comes to new clients, but they're great at extracting every last drop of revenue from their legacy client base.

Their contracting arm is most notorious for massive boondoggles (USAF's ECSS, scrapped after a billion dollars of sunk costs; Cover Oregon, which ended in recriminations, lawsuits and an FBI criminal investigation), and its software was at the epicenter of the HealthCare.gov catastrophe. Oracle could have owned cloud computing -- hell, they bought the company that reinvented the concept and instead tried to use it to force expensive hardware purchases on their expensive software customers. Now they're a minor player in a field that is steadily expanding to cover their core business sector and they're milking their cash cows furiously in an attempt to extract maximum value from a dying field.

In other words, they're Blockbuster the year after Netflix debuted streaming; their model is faltering and they don't know how to replace it and still stay in business.

No, they're not evil, just a nasty piece of work to do business with, and they're not stupid, but they're slowly dying. I only wish they weren't taking the last remains of Sun with them.

Yeah, it's sad how they caught Sun in their web and laid their eggs in its body. I was hoping IBM would buy Sun, and give the body a decent burial.

All the responses to this thread on Quora (many of whom are ex Oracle employees) seem to suggest that they are disliked:


"You actually don't need to be open minded about Oracle. You are wasting the openness of your mind. Go be open minded about lots of other things. I mean, let's face it: it's work to be open minded, right? I mean, you've got to constantly discard data and be like "ok, I need to be open minded about this". No, with Oracle, just be close-minded. It's a lot easier. Because the thing about Oracle, and this is just amazing to me, is, you know: what makes life worth living is the fact that stereotypes aren't true, in general. It's the complexity of life. And as you know people, as you learn about things, you realize that these generalizations we have, virtually to a generalization, are false. Well except for this one, as it turns out. What you think of Oracle is even truer than you think it is. There has been no entity in human history with less complexity or nuance to it than Oracle." -Bryan M. Cantrill


And later on he warns:

"Do not fall into the trap of anthropomorphizing Larry Ellison!" -Bryan M. Cantrill

... And now I have a new baseline as to what a pissed off software engineer looks like.

Disliked isn't evil. People should stop throwing around that word so easily though.

What they did to Peoplesoft was evil.

> The resurgence of Microsoft shows that being open and transparent is the actual winning strategy.

Or at least being a little bit open and transparent enough to build good will, anyway. There's a lot of non-open, non-transparent, non-friendly things about Windows 10.

I believe the OP was referring to the openness and transparency in .net, c#, typescript and visual studio code.

He probably was but the way he phrased it he made it sound like Microsoft is widely open and trustworthy, when it's not. Some teams are able to be open and transparent, but the company as a whole is not.

>>The resurgence of Microsoft

No, this shows you can be a dick and promise to stop and everything will be forgiven.

I don't recall Microsoft saying that they would promise to stop. What they've done instead was to act in more honorable ways. The jury is still out when it comes to forgiveness, but they've made a pretty good start at it.

It's not just a promise. They have open sourced basically all the core parts of their developer infrastructure. What twitter did was be a dick and then promise to do better whereas Microsoft is actually doing it.

Given Windows 10 and its phone home approach, they are still acting like a bad player.

The trademark is orthogonal to the license and its patent grant. Why would Google be particularly concerned whether they can call what they ship "OpenJDK"?

Because ultimately the trademark is as much the "thing" as anything else could be said to be, at least as far as I could think it through.

Everything I can read also makes it seem like the patent grants (above the GPL) are all tied to the condition of generating a compatible implementation of Java.

If Google wants to fork OpenJDK at some point down the road, they'd better have faith in the GPL.

"As such, Google wants to put more resources into OpenJDK where the team can have a bigger impact on new features and improvements."

That seems to answer that question, I think?

It doesn't mean OpenJDK will actually benefit from the improvements. All that's required from GPL is that you make the improvements available, not that you work with the upstream team to get them into master.

that would mean that google was interested in forking openjdk, which is certainly possible, though i kinda doubt.

>When we asked Google why now, the company pointed to to the release of Java 8 last year and the introduction of new language features such as lambdas. As such, Google wants to put more resources into OpenJDK where the team can have a bigger impact on new features and improvements. That’s the developer story Google is pitching in any case, but there’s a massive legal narrative here that can’t be forgotten.

Yes, the legal narrative is certainly key here, but as a dev I'm all for a move that brings Java 8 to Android instead of just Java 6. It's about time!

You wanna know what I did?

    1. Use RetroLambda
    2. Write your own implementation of Streams and Optionals, compatible with RxJava and Guava
    3. Use in your project
    4. Profit

well that doesn't really scale at all though

Ok, in what way does it not "scale"?

I do this, you do this. We try to use each other's code. Now there's two competing implementations that are probably incompatible.

No one should expect everyone to do that. This is basic, platform level stuff, that Google should be providing, unless they want Android to stagnate and whither away.

Obviously. But by now most have accepted that Google is just unable to provide any reasonable solution to this, and built their own libraries.

Often (ButterKnife, NineOldAndroids, etc) even better than what Google themselves provide.

Please explain it like I'm five: what is the big deal about lamdas?

I think this StackExchange question is pretty useful. http://programmers.stackexchange.com/questions/107687/what-i...

I will assume, for the purpose of this answer, that you mean "what is the big deal about Java 8 getting lambdas?". For other meanings of your question, see other replies.

In (pre-8) Java, variables can only hold primitive values or objects (in Java, an object is an instance of a class [c.f.]). Similarly, arguments to a method must all be primitive values or objects.

This is kinda crazy, by which I mean hilariously limiting. It's often useful to pass around other types of things, including types (in Java that'd be primitive types or classes or interfaces), or functions, or partially applied functions, or whatever. Of course, Java doesn't have functions, only methods. Whoops. See http://steve-yegge.blogspot.ca/2006/03/execution-in-kingdom-... for a bit of snark about how silly this whole situation is.

So Java programmers, while desperately lacking in aesthetic taste (I keed, I keed) and largely blinkered by the java-cultural context in which they find themselves, turn out to be a pretty clever lot after all. Clever enough that despite their language, they come up with all these conventions for doing things like passing around types and functions and so on. So you get ideas like the Runnable interface, wherein one makes a class just so that it can have a static method (perhaps called "run") that does what the function would do, and you then instantiate that class, and pass the instance, just so it can be used to get at the "run" method. It works, but it's oh so ugly.

So finally, after twenty years of this suffering, now Java programmers have some nice new syntactic sugar, to allow them to pass functions around with less explicit ceremony, thereby catching up with advanced languages like Python, C, Lisp, and basically everything except Cobol. Of course, under the hood it's still Predicate<T>, a generic type that represents a functional interface, which is a new bit of jargon they came up with to shoehorn this elementary functionality into their baroque conceptual framework. And you furthermore, in Java 8 you can even declare them anonymously (unlike e.g. C, AFAIK), to expedite the most common use case, which is passing a function as an argument to a higher-order function (like "map" or whatever). They're called "lambdas" because of the existence of the lambda calculus, an abstraction for computing that uses nothing but anonymous functions, and because many other languages have therefore referred to their anonymous function syntax as "lambdas" (Python even uses "lambda" as a keyword for this).

So the big deal about lambdas in Java is that Java has one less vile pain point.

(Any five-year-old could understand this explanation, right?)

For the record, some COBOL dialects appear to have function pointers. http://www-01.ibm.com/support/knowledgecenter/SS6SG3_4.1.0/c...

Ok, so I think I'm half way there. Is passing a function pointer, or any pointer for that matter, the way it is done in C, related to lambdas?

I understand the use case of passing functions. Can be quite useful. Ok, still not fully there but I think I'm starting to understand what you are talking about.

It's useful to be able to pass functions. In C, the mechanism for doing so is the function pointer. Function pointers feel really complicated, relative to most other features in C, and relative to the mechanism for passing functions in other languages that allow it, but yeah, they do the job.

Consider, for example, how you'd pass a specialized comparator to a generalized quicksort function. In C, you pass a function pointer to a cmp() function. In Python you just pass a function, because functions are first-class values that you can use like anything else - you can pass it by name, or you can pass a lambda. In Javascript you can do like in Python, or you can declare a full-fledged function anonymously inline. In pre-8 Java, you have to pass a weird object that instantiates a class that has a static method with the right name; this is ugly as shit, but it does WORK. In Java 8 you've got lambdas, so that sucks less.

It's not like you can do anything you couldn't do before. It's just a little less stupid now.

Got it. One thing that really bothers me is the name lambda. It seems to be used for something I'm already familiar with and have used plenty before but with the added benefit of obfuscation to make me feel stupid. I wonder if somebody is trying to make themselves feel smarter or I'm just stupid. Anyhow, KISS.

Lambda calculus was invented in 1937 to describe this concept; it existed before function pointers, so the name is actually accurate, you're just not familiar with it.

Its a lot more syntactical sugar.

Not a Java dev but what are these proprietary Java APIs? doesn't oracle jdk and openjdk share the same APIs?

I think the article is incorrect. I suspect they meant "implementation" rather than "APIs". As I understand it, OpenJDK has the same APIs (otherwise Google wouldn't be able to just switch to OpenJDK).

The article is a trainwreck. There is no difference between the Oracle Java API's and the OpenJDK API's.

There are, actually. The Oracle JDK has some features that the OpenJDK does not. Look at the 'commercial features' to see what: examples include the resource management API, AppCDS, Flight Recorder, a few other things I forgot.

Yes, but the context of the article was in relation to the 37 API SSO's Oracle accused Google of copying.

I think it's like this: Google copies Java's API. Oracle sues Google, claiming "You copied our API! It's copyright! You're infringing!" Google says, "Fine. We'll stop using your copyrighted API. We're going to copy the API of OpenJDK, which is GPLed so we're completely free to do so, and which just happens to have the exact same API. Good luck suing us for that one."

And the actual Android API doesn't change...

They're not "copying the OpenJDK API".

They're changing the Android Java runtime to actually use OpenJDK rather than its own proprietary implementation of the Java APIs.

Which is, perhaps, all that Oracle wanted all along.

Ater all, everybody wins from this.

- Android developers get up-to-date Java APIs that aren't years behind other Java platforms.

- Google gets to spend its engineering resources on things that matter specifically to Android rather than endlessly duplicating, and playing catch-up, to the OpenJDK platform.

- And Oracle gets a major industry player behind Java rather than fragmenting it and creating a slightly-incompatible variant.

Google's implementation isn't proprietary, it is Apache licensed. I think the idea of the parent comments holds. The irony is exquisite. Google is solving their copyright infringement problem by copying & distributing vastly more Oracle code.

It's not necessarily ironic. Oracle (or specifically Sun, which Oracle purchased) chose to create and distribute OpenJDK. They didn't choose to create Google's competing implementation, which perhaps they view as fragmenting the Java ecosystem.

Sun actually released the OpenJDK in response to the implementation that Android uses (Apache Harmony, not "proprietary Google").


That's true. It seems that alternatively Google could have relicensed their implementation as GPL and not have had to make any technical changes at all. Which shows that the only reason Google was maintaining their own implementation, and why they went through the lawsuit was just to keep GPL license out of their Java code. Seems nonsensical.

Google could not relicense APL code they did not write to GPLv2. The Java implementation is a subset of Apache Harmony, which they did not create from scratch.

Oracle maintains ownership of the OpenJDK project, which is the point here. Google simply relicensing its reimplementation of the Java APIs would not change the fact that the reimplementation is infringing under the law.

> Java APIs would not change the fact that the reimplementation is infringing under the law.

That's not an established fact at all. There is a whole lawsuit going on about it, if you haven't heard. If the final ruling is that APIs can be copyrighted, I'll change careers and never buy/condone the purchade of an Oracle product for as long as I live.

My exact thoughts as well. Perhaps they have to use OpenJDK instead of their own implementation in order to use the protected Java API?

They do but there might be an important point embedded here. The OSS implementation is licensed for free use. That implies the API is authorized for that version. The two issues go hand in hand Im guessing.

from my understanding, openjdk is insulated from the supposed copyrighted api issue, though they still struggle with obtaining a test suite that can certify their implementation as "compatible", to some degree or another.

No, OpenJDK is the actual reference implementation. It's Apache Harmony that couldn't get the TDK.

So why didn't they go this direction at the start?

OpenJDK didn't exist in the early days of Android, so it wasn't an option.

Sun/Oracle created OpenJDK, effectively "open sourcing" Java in response to the popularity of clean-room Java reimplementations like GNU Classpath and Apache Harmony.

Why Android did not choose to adopt OpenJDK until now, however, is a mystery known only to Google. Maybe it was just a lot of work, technically speaking, to do so.

ah, thanks for the clarification

So far APIs cannot be copyrighted. There have been lawsuits over APIs but no decision that protects APIs from being used by other people and companies.

GNU/Linux for example uses Unix APIs and Mac OSX uses Unix APIs, so if APIs are copyrighted then they would be sued for using the Unix APIs without permission. Then they would have to remove Unix APIs and lose Unix compatibility.

Sun went after Microsoft and others over Java IP before Oracle bought them out. Sun used a lot of money on lawsuits and ended up losing money to the point that Oracle bought them out. This is the same as when SCO was suing over GNU/Linux using Unix source code. It usually doesn't work and costs more in court costs than any settlement or rewards.

Ummm... "For the foregoing reasons, we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages at issue are entitled to copyright protection. We therefore reverse the district court’s copyrightability determination with instructions to reinstate the jury’s infringement verdict. Because the jury hung on fair use, we remand Google’s fair use defense for further proceedings consistent with this decision. "


And just to save others some time, "declaring code" is defined in this footnote:

'Every package consists of two types of source code— what the parties call (1)declaring code; and (2) implementing code. Declaring code is the expression that identifies the prewritten function and is sometimes referred to as the "declaration" or "header." As the district court explained, the "main point is that this header line of code introduces the method body and specifies very precisely the inputs, name and other functionality." Id. at 979-80. The expressions used by the programmer from the declaring code command the computer to execute the associated implementing code, which gives the computer the step-by-step instructions for carrying out the declared function.'

> So far APIs cannot be copyrighted. There have been lawsuits over APIs but no decision that protects APIs from being used by other people and companies.

What about the decision of the Court of Appeals for the Federal Circuit in Oracle America, Inc. v. Google, Inc.? [1]

[1] http://www.cafc.uscourts.gov/content/oracle-america-inc-v-go...

IANAL. Was that a decision that APIs were copyrightable, or that the trial judge couldn't definitively rule that they weren't?

[Edit: Ah, I see that this was answered by phonon in a post parallel to the parent. The appeals court ruled that they were. Note, however, that the Supreme Court declined to listen to an appeal by Google at this time. The Supreme Court did not rule that the Appeals Court was correct. Therein lies some hope...]

As I understand it, that's not how it works. When the Federal Circuit issued its decision saying APIs are copyright eligible, Google appealed to the Supreme Court, claiming the decision was incorrect. The Supreme Court, however, declined to hear the case, strongly implying (or maybe directly indicating?) that it thought the decision was correct. As such, there is no hope, at least as far as this case is concerned.

>The Supreme Court, however, declined to hear the case, strongly implying (or maybe directly indicating?) that it thought the decision was correct.

As the court emphasized in Missouri v Jenkins (1995), "[t]he denial of a writ of certiorari imports no expression of opinion upon the merits of the case" (https://www.law.cornell.edu/supct/html/93-1823.ZO.html)

The way I read it, it is not just the APIs but Google copied source code from Java for use in Android:

With respect to the 37 packages at issue, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.” Id. To achieve this result, Google copied the declaring source code from the 37 Java API packages verbatim, inserting ORACLE AMERICA, INC. v. GOOGLE INC. 11 that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages— the “overall system of organized names—covering 37 packages, with over six hundred classes, with over six thousand methods.” Copyrightability Decision, 872 F. Supp. 2d at 999. The parties and district court referred to this taxonomy of expressions as the “structure, sequence, and organization” or “SSO” of the 37 packages. It is undisputed, however, that Google wrote its own implementing code, except with respect to: (1) the rangeCheck function, which consisted of nine lines of code; and (2) eight decompiled security files.

> "Google copied the declaring source code..."

That is, Google copied the API. That's the declarations. That includes the package, class, and method names (and signatures) - that's what an API is in Java.

That's how I read this case as well. I've always been confused by the "API copyright" panic: If Google hadn't copied Oracle's source files (albeit interface-only source files) nearly verbatim, there would have been no liability. You're free to reproduce an API to provide to your clients; you're not free to take the interface files I wrote to provide the API, edit them a bit, and ship them as your product.

If I'm getting this wrong, I'd appreciate an explanation why.

There's no other way to "reproduce an API" in Java than to copy the names of methods, classes, interfaces, and packages verbatim. Otherwise, it would not be a compatible API.

The numbers in the telephone book are not copyright-able. You are perfectly able to produce a book of phone numbers in the same order and distribute it. However, if you were to photocopy an existing telephone book then you would be violating copyright.

Google did not produce their own compatible files containing the list of methods, classes, and interfaces. They copied Oracle's files.

> Google did not produce their own compatible files containing the list of methods, classes, and interfaces

No, that's exactly what Google did.

Google didn't copy any of Oracle's files -- except for 9 lines of code in rangeCheck and a few tests, none of which are central to the case.

> So far APIs cannot be copyrighted. There have been lawsuits over APIs but no decision that protects APIs from being used by other people and companies.

So, are you not familiar with the very very pertinent to this _particular_ platform recent case of Oracle v. Google?

Cause, yeah, that did that. It's a disaster.

I was not aware that Oracle won. Can Google appeal it?

Google appealed to the Supreme Court. They declined to hear the case.

I think the HN speculation yesterday that there's been a settlement is wrong. This is Google moving to protect itself going forward after it lost the case in the Federal Circuit. That case was sent back down to the lower court only for ruling if Google's use of Oracle's now apparently copyrighted APIs consists of "Fair Use". Since APIs are now copyrightable I don't see how copying thousands of APIs could possibly consist of "Fair Use" so it's looking like Oracle is going to get paid, big time. And Oracle will probably demand a royalty for every phone sold. So in order for Google to avoid paying that royalty going forward they need to move to OpenJDK quickly with their next release, with the belief that using Oracle's GPL JDK implementation also gives them a license to the API. Problem for Google is that OEM and user adoption of new Android versions is slow, it takes several years for phones with old versions to stop selling, and Oracle will get a cut of each sale.

In any case, I think this is a healthy development for Java developers and the Java ecosystem. Java has been effectively forked between Android and other uses and this will unify the language again. And it will bring the cool new Java 8 features to Android.

The answer is, it's fair use if you are trying to be compatible - DR-DOS could be considered a fair use copy of the MS-DOS APIs, because that's the only way to run DOS programs. But ordinary Java programs don't run on Android and Android programs don't run on the JVM. So Google lacks a fair use defense as far as I can tell.

I am sorry to see your comment was downvoted, as it is quite correct: if you read the actual court documents, this is the argument that was made surrounding fair use, and despite their attempts to lie and say they were, Google could not be shown to be trying to build a compatible product (as it is pretty obvious even to non-technical people that they aren't and never intended to even try). Back when this was first being published I wrote a much longer comment pointing out all of the intricacies and quoting the court opinion.


Having tried it myself, standard JVMs and Java bytecode are problematic if you intend to create an efficient handset OS. Danger and Android did a lot of interesting things to Java to make it work better, and the Android runtime has evolved away from from what JVMs look like for some very good reasons.

This isn't about the VM, it's about the code that runs on the VM. The Java language code, for example Object.equals(), that gets compiled into Dalvik/ART bytecode will now be OpenJDK code instead of Google's own implementation.

Google not buying sun was huge mistake.at least they could sell it after keeping java.something like what they did with Motorola. They kept all patent's. They could have done the same with java.

Consider Google bought Motorola for $12.5B[1] and Oracle bought Sun for $5.6 billion[2], I would think Google buying Sun would have been a better deal than buying Motorola.

1) http://bgr.com/2014/02/13/google-motorola-sale-interview-len...

2) https://en.wikipedia.org/wiki/Sun_acquisition_by_Oracle

Perhaps, but it's not like Google lost much by buying Motorola.

"I think the Motorola transaction has been a success for us. Financially, we bought the asset for $12.5 billion. It had $3 billion in cash; we were able to sell the Home division for $2.5 billion; we ended selling the handset division for $3 billion. There were some other tax assets as well. When you work through the math, you realize we spent between $2.5 billion and $3.5 billion for the patent assets. At the time, the nearest comparable transaction was the Nortel patent auction where Microsoft and Apple teamed up to buy that asset for $4.5 billion. And there’s a good argument that the Motorola patent portfolio is a better portfolio."

Nice informative quote is missing an attribution. Google finds it in an interview in Forbes with Dan Harrison, Google's head of M&A.

Motorola was threatening to start suing other Android ODMs which would have wrought havoc from within the ecosystem. IIRC, Sun was a lot more forgiving and basically willing to look the other way at Google playing fast & loose with Java stuff. It was not yet in the offing that a) Sun was for sale, or b) Oracle would be the one to buy them within 2-3 years almost exclusively to bludgeon Google with the IP. In hindsight, it would have made all the sense in the world. Back then, I don't think it was clear it would be necessary and would have surprised people in a negative way probably ("Google's going to sell SPARC servers, now?" -- remember IP was not the stated reason for buying Motorola even if it's obvious that is what it was about now - at the time Google claimed to want to make devices). Connecting the dots forward is hard.

Sun specifically approached IBM for merger talks, I have a hard time believing they were that secret given Oracle's actions. Looking at the threats, Sun under more litigious hands probably was more of a threat than Motorola.

Title is confusing, OpenJDK does belong to Oracle and Google is going to use it. It's just that the OpenJDK is GPL.

And the GPL will make it really hard for Oracle to prevent Google from using it in Android.

But doesn't Google tries to avoid GPL?

I think they're pretty anti-GPL with Android, and have some rules against inclusion of GPLed components there, besides the kernel. I think the whole userspace is under non-copyleftish BSD/MIT/etc.

(Tedious disclaimer: not speaking for anybody else, my opinion only, etc. I'm an SRE at Google.)

> But doesn't Google tries to avoid GPL?


> I think they're pretty anti-GPL with Android, and have some rules against inclusion of GPLed components there, besides the kernel.

OEMs don't want their hardware support to be GPL-encumbered. See https://source.android.com/source/licenses.html

That's picking some major nits: whatever you want to claim is Google's internal mental opinion of GPL, the reality is they are building Android to cater to hardware manufactures, and those hardware manufactures do not want GPL, so Google has actively avoided GPL code in Android, often going to extreme lengths to build half-asses reimplementations of things that have perfectly stable GPL implementations so they don't have to rely on code using that license.

The JDK stays inside the development environment. The development toolchain translates Java bytecode to Dalvik bytecode. There are probably a few other GPL components in the toolchain, although they are transitioning away from GCC in the NDK.

also, it comes with a patent grant

Thank you for this.. that was my question, in a different comment. I was curious how using OpenJDK would prevent a similar lawsuit... Also, does this mean that Dalvik will be enhanced to support Java's compiled modules directly, or are they outright replacing Dalvik?

TFA doesn't make much of this all that clear to me. Though I admit I only skimmed it.

Dalvik is already retired and replaced by ART.

Judging from the commits on AOSP, ART is still being worked on and has been adapted to openjdk.

It looks like it is here to stay.

Useful to some degree, but if I understand correctly, patents are not part of Oracle's suit.

There were, but the jury found non-infringement on both.

Isn't OpenJDK under the GPLv2, which does not come with a patent grant?

The title says Google won't use Oracle's proprietary APIs, which seems clear enough.

The original article title was changed to "Google won't implement Oracle's proprietary Java APIs", which makes more sense. This isn't about some special new APIs, it's about Google switching to the OpenJDK for the core APIs from its Harmony-based reimplementation.

Ok, we'll follow suit.

It's also interesting to note that this is essentially the outcome advocated by the FSF in its amicus brief to the federal circuit. https://www.eff.org/cases/oracle-v-google

Question: why didn't Android use OpenJDK in the first place?

Well they based most of their original implementation on Apache Harmony. Just speculating here but it may have been due to dates. OpenJDK's first release was ~2007 but IIRC the original pre-Google Android team started work in 2003 or 2004.

OpenJDK starts much slower and consumes more memory than Dalvik and some official Java APIs are terrible (e.g. AWT); it's likely that Android would have failed if it used official Java.


This is a good study in why that's irrational.

No, OpenJDK didn't exist when Android was in development.

I wish they could get away from java. I like the language and the platform, but maybe something like go would be better.

Completely subjective here but no Go would not be better. Java has generics. Java has more support, more tooling and Android's existing eco system is fully mature. If they started out from scratch it would result in worse language with less tooling and a smaller ecosystem.

Well, I did say I wish they "could".

One language which seems to be under consideration is Dart. Check out Flutter[1]


We already have something better than both Java and Go and it runs flawlessly on Android: Kotlin.

Or Swift.

This is a huge win for open source if Google is going to build on OpenJDK. The implicit patent grants are huge! They can even pour resources into building a better GPL'd run time. So much of Google's internals are written in Java that they would certainly benefit from this.

Looks like another LibreOffice/OpenOffice Jenkins/Hudson split in the making. You'd think Oracle would have learned by now.

I wonder if they'll fork the Java language standard? That would seriously damage Oracle if it got traction. They couldn't use Oracle's trademarks but people are familiar enough now with Dalvik that they could just introduce Dalvik Server Edition and people would lap it up.

OpenJDK is under GPLv2. There are no patent grants.

Your statement is confusing (and possibly wrong depending on how it's read).

There are no patent grants in GPLv2. However, OpenJDK carries an automatic patent grant (outside of GPLv2).

It makes sense. It future-proofs androids ongoing legal viability. If they haven't yet settled with Oracle then it also strengthens their negotiating position on the issue of damages for copying API signatures. Thanks Appeals court!

It also makes sense in light of Google's recent announcement that they are going to be shipping a desktop android os with chrome on it soon.

Unlike in 2008, Google no longer has to worry if phone vendors care about whether the runtime is GPL+classpath, which was probably the original motivation for an apache licensed runtime.

There is still however, the mystery of why the commit is missing the openjdk LICENSE file, or any mention of Oracle at all.

I thought this was rather interesting:

OCTLA Signatories List

The following organizations and individuals have signed the OpenJDK Community TCK License Agreement (OCTLA) and been granted access to the JCK.

  Signatories for Java SE 6
  Azul Systems, Inc.
  CACAO - Christian Thalinger
  Cambridge Software Labs - Edward Nevill
  Canonical - Matthias Klose
  Red Hat
  Stratus Technologies

Google has been an OpenJDK contributor for server-side stuff for a while.

I am kinda surprised they have not proposed a language (new or existing non-Java) yet for their phones. I thought this would at least be in the plans so they do not have to rely on Java alone. A big task for sure.

Perhaps they are waiting for Web Assembly to become mainstream. Then do a side-by-side:

1) Web Assembly -> new VM

2) Existing Java Apps -> Dalvik

With 2) eventually being phased out.

Edit: As pointed out below it is no longer Dalvik, but ART.

JVM bytecode or Dalvik bytecode already fill the purpose of WebAssembly.

Seems like it would be massively messy to move to anything but another JVM language, considering the long history of Java-based Android. Matter of fact, I'm having trouble thinking of an example of any major platform making such a fundamental change and surviving. Maybe Apple switching from OS9 to OSX/Cocoa. They started building the Carbon compatibility layer, what, 2-3 years ahead of the switch, and IIRC the API is still available today, though considered deprecated. And no version of MacOS had anywhere near the adoption level or number of third-party apps as Android does.

Before that Apple had to move from Motorola 68K ISA to PPC.

I think they were trying something with Dart but it didn't get enough traction. If it had then it might have become a first class citizen on Android.

They still are. Have a look at flutter.io

Which would be a horrible end for everyone.

(Also, after they’ve just replaced Dalvik with ART, this isn’t very likely)

Go has started to roll out support for mobile devices.

AFAIK decent support is a ways down the road right now, though.

So does this mean that Android will be licensed under the GPL going forward?

If you distribute OpenJDK, then only the modules that are “derived from or based on” OpenJDK are required to be GPLv2[+CE] (the Classpath Exception allows you to link the library with an independent closed-source library). So I think it would only require platform/libcore itself to be released under GPLv2+CE. Probably manufacturers don’t need to modify platform/libcore too much anyway.

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

Again, the commit in question: https://android.googlesource.com/platform/libcore.git/+/51b1...

There's a bunch of GPL (or at least, open source) code in Android. Just go to Settings -> About phone -> Legal information -> Open source licenses and you'll see that lots and lots of parts of Android are open sourced (most of them using some version of GPL).

Parts of it yes. Just like the Linux kernel in Android is GPL.

I'd like to see Google pouring vast resources into OpenJDK development and making Oracle Java obsolete. That's the karma they should get for being Oracle.

Oracle Java is based on OpenJDK and certified by Oracle. So I don't see how pouring vast resources into OpenJDK would make "Oracle Java" obsolete.

> Oracle Java is based on OpenJDK

I don't think that's exactly the case. Oracle Java has some features that OpenJDK doesn't have. What if Google accelerated development of Open JDK beyond what Oracle is brewing so far that at some point Oracle will have a choice of just taking OpenJDK and stamping their brand on it (probably illegal) or being forgotten Java-wise?

Oracle runs OpenJDK. They aren't separate projects.

Google would only need to fork and rename though, then Oracle wouldn't be running it. If using the fork were a requirement to running on Android, that's a big draw.

I'm not sure Google is really interested in that though.

This battle is very important: two questions it will answer are these:

1. Are APIs copyrightable?

2. If APIs are copyrightable, does providing an alternative implementation of someone else's API (the way Android provided an alternative implementation for some of the standard Java APIs) constitute a fair use [1]?

Google and Oracle settling this out of court would be very bad news: it would leave the above issues in limbo. That is a lot of legal uncertainty for any project that may wish to provide an alternative implementation of someone else's API.

[1] https://en.wikipedia.org/wiki/Fair_use

EDIT: formatting

That issue is going to be in limbo even if they don't settle out of court, unless the Supreme Court eventually takes the case (or Congress steps in and modifies copyright law to clarify this).

That's because this case is both a patent case and a copyright case, and that messes up the normal appeals path. Copyright precedent in the 9th Circuit is set by the 9th Circuit Court of Appeals and by the Supreme Court, and that is also the normal appeals path from the district courts in the 9th Circuit.

When a case involves patents the appeals path is to the Court of Appeals for the Federal Circuit and then to the Supreme Court. CAFC rulings on patent issues set precedent for all district courts.

Not so for CAFC rulings on copyright issues. 9th Circuit district courts, for instance, considering API copyrights in the future will continue to look to what the 9th Circuit Court of Appeals has said on this. What the CAFC has said is no more binding on them than what the 5th Circuit or the 7th Circuit or any other non-9th Circuit, non-Supreme Court court has said.

This is a pretty messed up situation. When CAFC gets something like a copyright issue that comes along for the ride on a patent issue, they are supposed to follow the precedent of the circuit from whence the case came on that non-patent issue.

If they botch that, there is nowhere to appeal to except the Supreme Court. But since the CAFC ruling on the non-patent issue won't be binding on anyone except the parties in that one case, it is not likely that the Supreme Court will take the appeal. Eventually, the issue will arise again in that same district, but without being attached to a patent case, and then can be appealed to the Court of Appeals for that circuit where they can clarify what the correct interpretation is in their circuit.

>So the only reason why you may object is that my lisp.a has an INTERFACE that allows it to be linked to libreadline.a . As far as I know, only the readline CODE is copyrighted, not its INTERFACE. (Would you object because my libnoreadline.a has a similar interface?)


This is very interesting and highly relevant! Thanks!

I'd love to see a bigger push for golang support for Android.

Good news AFAICT! Hopefully Android:

1) Gets an updated kernel 2) Can run standard JVM bytecode 3) Switches to CGroups 4) Allows for interop with desktop/server JVM

On a side note, I wish WebAssembly would just be JVM byte codes instead of this huge NIH syndrome. No need for the importing the Java SDK, broken sandbox mode, and all the other crap that made Applets fail... just the JVM itself.

It is unlikely that Android will run Java bytecode. The Dalvik runtime was aimed at keeping bytcode compact and interpreting faster than a JVM. ART is a pre-compiling (Dalvik bytecode to native) runtime. Using Java bytecode in the runtime on the Android device would open a whole big can of worms again. With open source APIs and no actual Java(tm) technology in an apk or on a device once code is translated from Java bytecode to Dalvik bytecode, Android stays clear of Oracle copyright claims.

You can actually load Java bytecode on Android (since 1.x!) by manually using a separate classloader at runtime[1]. There are even J2ME runners that have been doing that since Android's early days[2].

[1] http://stackoverflow.com/questions/60764/how-should-i-load-j... [2] http://www.netmite.com/android/faq.html

Those approaches "dex" the Java bytecode and run Dalvik bytecode.

This would be great. The benefits of reuse of the toolchain and ecosystem alone are very compelling. That is another thing that will need to be reinvented by WebAssembly.

I couldn't figure out exactly which version of OpenJDK code they imported, but it's certainly less than 1.8.

1.7: as java.util.Objects is present ( https://android.googlesource.com/platform/libcore.git/+/mast... )

Sounds good. I hope that OpenJDK improves, because it's been sluggish and buggy in my experience. What Google should do is to move to something like Kotlin, which might make the whole programming environment less tedious than Java.

How does this obviate the patent issues? Or is there patent indemnification from Oracle(or formerly with Sun) with the OpenJDK license?

Is this really Google's best move to protect itself from Oracle? How safe is OpenJDK from Oracle?

OpenJDK is licensed under the GPL. So as long as Google doesn't violate the terms of the GPL it's quite safe to use it. In addition, the GPL provides an implicit patent grant to the code: https://copyleft.org/guide/comprehensive-gpl-guidech7.html

OpenJDK is the reference implementation of Java. The whole point of its GPL license is to ensure that the project forever remains with the community.

Will this introduce multiple version issues into JVM ecosystem like Python 2 vs Python 3?

I am so sorry, i was going to upvote you.but because of my small touch screen i down voted you.i am really sorry.

BTW i have exact same question.

We detached this subthread from https://news.ycombinator.com/item?id=10809557 and marked it off-topic.

I wish there was an option to disable the downvote arrow on comments, or only show the downvote arrow if I click the direct link for a comment (like with flagging comments).

I'd rather not create a new HN account just to read and reply on mobile without the risk of accidentally hitting a downvote button while scrolling or trying to upvote a comment.

You can install the stylebot [0] extension for Chrome, or stylish [1] for Firefox, then a rule like:

    div.votearrow.rotate180 {
        display: none;
should do it.

[0] https://chrome.google.com/webstore/detail/stylebot/oiaejidbm...

[1] https://addons.mozilla.org/en-US/firefox/addon/stylish/

Thanks for the suggestion. I've used Stylish on both desktop Firefox and Chrome before. Would you say Stylebot is better?

Unfortunately, mobile Chrome doesn't support extensions, but maybe this would be a good excuse to use mobile Firefox more.

I like Stylebot more. It integrates into the webpage better, so you can have live previews, and right click on an element to style in [0], and for basic changes (such as hiding elements) you can avoid touching CSS at all.

[0] Of course, it just takes its best guess as to which possible selector you really want to style when you do it this way.

I wish the down vote arrow appeared at the end of the line instead of under the up vote arrow.

  /\ someuser 30 minutes ago \/

This. I thought the same yesterday. And I don't even have down vote buttons!

The recurring discussion about it gets old. Fix it.

I have upvoted to counteract your downvote. Order is now restored in the universe.

I have also upvoted in case you wanted to upvote yourself. How's the balance now?

As someone who had a neutral opinion of the importance of parent comment, I instead upvoted, thereby proxying and honoring your original intent in combination with tedivm.

Relevant HN discussion, so we go full circle: https://news.ycombinator.com/item?id=10803775

Crazy... here we have a Hacker News comment on a Venture Beat article about a Hacker News post about a Google code commit.

So full circle would actually be referencing this discussion in an android commit. :)

Don't forget creating a wikipedia article referencing both this discussion and the commit as sources.

I wish they had an agreement with Apple for the next 10 years for the use of Swift so we could write our apps once and run everywhere.

But we all know the NIH syndrome, which is a shame since everybody is adopting Google's web extensions standards and they should adopt whatever is best for all in other technologies too.

Swift? As an Android Developer I think it would not be a great idea. C# maybe a better language(wasn't that open sourced?). It much closer to java than swift is and would allow people like me to move cover over faster.

I started off as a C# developer and had not done any real work in java before. I was able to move my C# code(couple thousand lines of code) over to Java in a matter of hours.

Anyway I do not wish or hope for a language change period.

Given that you know C# and Java, you should not have a great deal of trouble learning other C-family languages, including Swift.

Objective-C was/is a bit of an exception to this, as it's "funky" syntax could be a bit intimidating to developers coming from other languages - one of the motivations for Apple's switch to Swift was to address this.

You do realize the JVM and related bytecode have been along around _a lot longer_ than Swift.... right?

And,uh,wasn't invented by Google.

They wouldn't need an agreement with Apple.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact