That's not exactly the same. Oracle is infamous for bait and switch, where it's free at first. With Java, they first snuck in some extra components that triggered license requirements, then later, just changed the whole jdk license.
They are very aware that big companies wouldn't be nimble enough to switch to openjdk in time to avoid the license fees.
Additionally, they know that companies have 3rd party software that bundles what was once "free" oracle jdk. The end user gets to foot the bill for that rather than the 3rd party.
Infamous or not, the licensing situation is now clearer and better than ever before: Oracle offers the same software under a commercial license for those who wish to buy support, or under a free license to those who don't. The download pages for either option clearly identify the license, and point the user to the other option, if that's what they want:
The companies that were caught up in this are, for the most part, the ones on Oracle JDK 8, which is substantially different than OpenJDK.
The "UnlockCommercialFeatures" doesn't catch everything either. For example, Oracle once added a clause about "embedded devices" needing a commercial license. With a very broad definition of embedded.
This is pretty clearly a cash grab.
Also, If the bits are truly the same as of version 11... what's the point of making people download a duplicate codebase where the only difference is one text license file?
> For example, Oracle once added a clause about "embedded devices" needing a commercial license. With a very broad definition of embedded.
No, field-of-use restrictions had applied under Sun, too, as licensing Java to mobile/embedded devices was Java's income source. Later, various commercial features were also a source of income. Oracle has now completely opened the JDK (and there are no field-of-use restrictions for the free license), opened all commercial features, and has switched to a support model.
Like all companies providing open source runtimes/languages, Oracle, too, must fund Java somehow (as I explained in another comment https://news.ycombinator.com/item?id=19069655). You're free to think that the funding model now is less preferable to you personally than the previous ones, but I don't think anyone can claim it is any more of a "cash grab" than the previous monetization strategies.
I think that if anyone claims that recent changes to Java's licensing and release models are not for the better, then they are either misled or misleading.
Ahh, yes, you're right. The clause was there. But Sun, in practice, applied it to things that most people would call "embedded". Oracle used a broader definition that included PC hardware in many situations.
Not sure I understand the whole funding argument. Swift, golang, v8, typescript, etc, seem to be fine as open source.
Golang, V8 and TypeScript are tiny projects compared to OpenJDK. Oracle employs hundreds of full-time OpenJDK contributors. Swift is funded through iOS (just as .NET is funded through Windows and Android through, well, Android). I don't know if this is true anymore, but the number of people developing Golang at Google is (or used to be, last I heard) close to the number of people there modifying OpenJDK for their internal use. V8 is also funded through Chrome, BTW.
I'm mystified as to why Java is so much bigger than any pure open source language implementation.
In any case all this jockeying around with the license will certainly reduce the user base. From talking to my peers at other companies, we're all putting together our "get off of java" plans now.
Why? Because the requirements are so much more challenging. OpenJDK has several state-of-the-art GCs (e.g. for software that values throughput, software that values latency, and software that's in between), three state-of-the-art compilers (C1, C2 and Graal) plus the frontend compiler, javac, and an extensive standard library. People rely on Java for projects that are much more demanding than those using, say, Python, Go, Node.JS etc. .NET is of a similar size, because the demands are similarly high.
I can tell you that the amount of software switching from other platforms to Java is significantly higher than that switching away. Those switching away are those with lesser requirements (e.g. in terms of performance, data size, management and tooling), and those switching to Java do that because they want the scalability and tooling. The full open-sourcing of the JDK and the new release cadence are big improvements that make Java even more attractive to those that were on the fence before, and the pipeline of major OpenJDK projects (Valhalla, Amber, Panama, Loom, Metropolis) is deeper than ever in Java's history.
Most of the companies I work with are either Java or .NET shops, moving away from any of those platforms means rebuilding their business, for some of them, even the services that they sell, throw out worldwide trainings moving the whole company into a new stack.
A large majority of corporations aren't that allergic to software licenses, they have other issues on their top list.
Swift is reasonably independent from Apple these days. It’s stable starting version 5 and most new features are geared towards other applications than Cocoa.
These are great options. If you don't want to pay up to Oracle. Just use one of the OpenJDK distributions. Java is still free and the JVM is still an amazing piece of tech.
Isn't it nicer to just... not use anything related to Oracle though? Oracle still holds a tremendous amount of power over OpenJDK, right?
Oracle has also demonstrated in court that the Java API is their intellectual property, and that they are willing to go after people for reimplementing them. OpenJDK might be blessed, but I'd still be afraid of having anything to do with their intellectual property. That's also one of the primary reasons I'm not very excited about ZFS.
> Oracle has also demonstrated in court that the Java API is their intellectual property, and that they are willing to go after people for reimplementing them. OpenJDK might be blessed, but I'd still be afraid of having anything to do with their intellectual property. That's also one of the primary reasons I'm not very excited about ZFS.
If you use OpenJDK you get an implicit patent grant to run OpenJDK (as it's licensed under the GPL).
If you use any other non-OpenJDK runtime you might still violate some of Oracle's patents, but you don't get any patent grant.
So if you're concerned about patents then using OpenJDK (instead of not using it) would actually be the safer way to go.
I think GP is pointing out that it would be far safer to not use Java in the first place. One day Oracle could decide to kill OpenJDK, and since they have a history of aggression towards non-Oracle distributions of Java you would be trapped if you depend on Java.
There are already lots of non-Oracle distributions of OpenJDK: Azul's Zulu, AdoptOpenJDK, Amazon's Corretto and I'm not aware of any aggression towards those projects. The lawsuit against Google targets an implementation that didn't derive from OpenJDK and is thus not covered by any of the patent grants.
Furthermore, OpenJDK is licensed under the GPL. Even if Oracle stopped contributing to OpenJDK the GPL license would ensure that OpenJDK and all derivative works can still be freely distributed and are still subject to Oracle's original implicit patent grant.
> There are already lots of non-Oracle distributions of OpenJDK: Azul's Zulu, AdoptOpenJDK, Amazon's Corretto and I'm not aware of any aggression towards those projects.
I don't see how that's relevant? I wasn't aware of any aggression towards Google, until Oracle suddenly decided to aggress. The fact that Oracle hasn't been aggressive towards non-Oracle OpenJDK distributions in the past doesn't mean they won't be aggressive in the future.
OpenJDK is licensed by Oracle under an open source license (and Google has made use of this license, and even internally forked OpenJDK, both during the trial and now). The court trial was over an unlicensed use of Java (Google claimed they didn't need a license because the APIs weren't Oracle's to license, but in any event, that lawsuit has absolutely nothing to do with OpenJDK).
Oh, that wasn't intended as an argument that OpenJDK is unsafe, I was just asking why it's relevant that Oracle hasn't shown aggression towards non-Oracle OpenJDK distributions yet, when nobody has brought up concerns about how Oracle already is aggressive towards OpenJDK distributions.
I can probably agree that Oracle is relatively unlikely to start coming after people for patent infringement related to using OpenJDK or forks thereof, when OpenJDK is licensed under a license with a patent grant. My biggest concern is just that Oracle seems like a thoroughly evil and unpredictable company, and I wouldn't like to use technology they own and which uses patents they own. I wouldn't have imagined that Oracle would ever come after people for re-implementing their API; I can't imagine what Oracle will do in the future, but I won't build a business or institution around the assumption that they will do nothing. It's not like there aren't a plethora of other solutions for anything developed by Oracle, most of which are better than Oracle's alternatives.
The copyright to non-Oracle OpenJDK distributions is still owned by Oracle, but Oracle licenses OpenJDK as free software (as in beer and in speech).
I think that even if it made sense to assign virtue judgments to corporations, it would be a huge stretch to claim that Oracle is any more evil than other companies of similar size, like Google, Facebook, Microsoft or Apple, but as I work for Oracle, I'm obviously biased.
It’s hard to say that when we’re still clamouring for generics without type-erasure. It’s been over 14 years since the CLR had it and it’s definitely holding back the Java ecosystem in my opinion.
Erased generics are awesome. Without erasure interop and code sharing among languages with different variance strategies is severely hampered. It's because Java erases generics (for subclassable reference types) that Java, Kotlin and Clojure can all share the same data structures without any runtime conversions.
I imagine it would help to keep binary size and compile times down too, though I don't know by how much.
I wonder if C++ compilers "collapse" things like `vector<Foo⋆>` and `vector<Bar⋆>` (or even `vector<size_t>`) if they can figure out that all of their respective methods end up generating the same machine code... Maybe not?
(Stars because I can't seem to escape asterisks properly...)
This is a fairly common optimization that is normally performed by the linker. [0] is a blog entry that describes Microsoft’s implementation of identical function merging.
Ooh, really cool. The comment about function-pointer comparisons was a pretty funny ramification I hadn't considered too. Real "wtf" debugging case I bet.
I wonder what the standard says about it, what the linker can/could typically prove is "safe", and what performance/size changes are seen in practice.
The paper Safe ICF in Gold[0] says that they get between 4 to 7% savings on code size. A safer version that omits functions that have their address taken was 97% as effective.
The talk Diet Templates[1] has some suggestions for how to reduce template bloat.
You want to erase generics because you don't want to bake a specific variance model into your runtime. Erasing generics allows languages with different variance (e.g. Java, Kotlin and Clojure) to share code and data structures. This is not an issue for generics of non-subtypable types, which is why generics of the forthcoming value types will be specialized rather than erased.
Holding it back compared to what? I come from a CLR background and look enviously at the jvm ecosystem all the time. Haskell, BEAM, etc are almost all a step down from jvm once you factor in tooling.
I work with both, so I do agree with you with my C# hat on.
On the other hand with my Java hat on, I look enviously to proper unsigned types, value types, explicit SIMD, and the language support for low level coding optimizations.
Still looking forward for Valhalla and Panama to arrive.
No, it is not. Most JVM languages (except Ceylon, I think) choose to erase generics, as that's the right thing to do if you want good polyglot interop.
No, I mean that the JVM itself doesn’t have opcodes for storing generics type info. Hence why it was done for backward compatability, they didn’t need to add or change instructions.
That's incorrect. You could specialize classes on the fly (and the opcodes for all reference types are the same, anyway). It's just that it's a bad idea to reify generics of reference (and so subtypable) types. You gain little and lose much.
It still makes no difference. All vendors offering OpenJDK builds offer it under the same license, as the license is dictated by the open source OpenJDK, which is owned and run by Oracle, and developed mostly by Oracle. If you actually read the license for any OpenJDK distribution, you'll see that the copyright for the software is owned by Oracle. So all OpenJDK distributions are equally "tainted".
If you're using Java now, its probably a good idea to start looking at migration to something not Java. And until the API lawsuit is resolved, even things like Kotlin are probably not safe.
And well, if you choose Java now, you're just a fool :/ It is a footgun and the trigger is controlled by a pack of lawyers at Oracle.
The API lawsuit has absolutely nothing to do with OpenJDK. OpenJDK is licensed to anyone under an open source license. The lawsuit relates to the use of code library APIs not in accordance with any license. Because the license is clear, whatever licensing situation you may have been afraid of before, things are strictly better now.
BTW, Google has used OpenJDK extensively even throughout the court case, and still does, and has even forked it internally.
> BTW, Google has used OpenJDK extensively even throughout the court case, and still does, and has even forked it internally.
But isn't that their problem? The Oracle claim is that APIs themselves are copyrighted , and need permission from Oracle to even use the APIs?
It wouldn't matter of the software package was licensed. If Oracle's argument is accepted, then even invoking the APIs need a separate license outside the permission to copy JDK.
I really hope the judge finds in favor of Google. APIs should absolutely not be copyrightable.. But that's the main issue. And I still stand by my assessment that Java-anything is harmful for your health. And if your company has $$$, using Java is attracting sharks.
Even if APIs are copyrighted, anything that's copyrighted can be licensed, and OpenJDK, which includes the Java APIs, is licensed under an open source license (which, BTW, Google did not use in Android until recently, but have used, and still do, for their use of OpenJDK).
Want to use commercial software? Pay accordingly.
Not wanting to pay for it? Plenty of options available.
https://adoptopenjdk.net/
https://aws.amazon.com/corretto/
https://www.azul.com/downloads/zulu/
https://www.eclipse.org/openj9/
https://developers.redhat.com/products/openjdk/download/