Google confirms next Android won’t implement Oracle's proprietary Java APIs
venturebeat.com
venturebeat.com
From what I gathered in the previous discussion, it's not a drop-in replacement - they made several changes to OpenJDK already.
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).
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.
And you sure as hell don't get to $10 billion a year in profits by being stupid.
https://youtu.be/-zRN7XLCRhc?t=33m1s
And later on he warns:
"Do not fall into the trap of anthropomorphizing Larry Ellison!" -Bryan M. Cantrill
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.
Too bad the ATF and Attorney General Janet Reno didn't take charge of the situation.
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>
No, this shows you can be a dick and promise to stop and everything will be forgiven.
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.
That seems to answer that question, I think?
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!
1. Use RetroLambda
2. Write your own implementation of Streams and Optionals, compatible with RxJava and Guava
3. Use in your project
4. ProfitOften (ButterKnife, NineOldAndroids, etc) even better than what Google themselves provide.
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?)
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.
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.
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.
And the actual Android API doesn't change...
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.
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.
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.
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.
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...
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.
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.
If I'm getting this wrong, I'd appreciate an explanation why.
Google did not produce their own compatible files containing the list of methods, classes, and interfaces. They copied Oracle's files.
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.
[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 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)
'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.'
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.
1) http://bgr.com/2014/02/13/google-motorola-sale-interview-len...
"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."
TFA doesn't make much of this all that clear to me. Though I admit I only skimmed it.
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.
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.
> But doesn't Google tries to avoid GPL?
No.
> 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
This is a good study in why that's irrational.
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.
There are no patent grants in GPLv2. However, OpenJDK carries an automatic patent grant (outside of GPLv2).
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.
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
Google
Red Hat
Stratus Technologies
tarent
Yozosoft
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.
(Also, after they’ve just replaced Dalvik with ART, this isn’t very likely)
AFAIK decent support is a ways down the road right now, though.
GPLv2+CE: http://openjdk.java.net/legal/gplv2+ce.html
Again, the commit in question: https://android.googlesource.com/platform/libcore.git/+/51b1...
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?
I'm not sure Google is really interested in that though.
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'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.
http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-...
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.
[1] http://stackoverflow.com/questions/60764/how-should-i-load-j... [2] http://www.netmite.com/android/faq.html
BTW i have exact same question.
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.
div.votearrow.rotate180 {
display: none;
}
[0] https://chrome.google.com/webstore/detail/stylebot/oiaejidbm...
Unfortunately, mobile Chrome doesn't support extensions, but maybe this would be a good excuse to use mobile Firefox more.
[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.
/\ someuser 30 minutes ago \/The recurring discussion about it gets old. Fix it.
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.
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.
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.