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.
