It has build instructions on the site, but not pre-built binaries for download. In the site that you linked, however, it says that Semeru does use it under the hood.
"AdoptOpenJDK up until now was producing OpenJDK binaries with both Hotspot and OpenJ9 VM's. With Adopt's move to Eclipse, legal restrictions prevent the new Eclipse Adoptium group from producing/releasing OpenJ9 based binaries. As a result, IBM will be producing OpenJ9 based binaries in 2 flavours, Open and Certified, both under the family name IBM Semeru Runtimes. Essentially the same binaries, released under different licenses."
Also they don't provide binaries because of an agreement with oracle to have access to some validation tools if I remember correctly, thus you need to use IBM semeru
OpenJ9 already did PGO, JIT cache and AOT compilation years before GraalVM, as it is based on IBM's commercial JVM implementations for their platforms and used to be the JVM for WebSphere (before Liberty rewrite).
I guess it is a pity if they decide to no longer invest on it.
At Atlassian in 2008, I noticed that they had acquired a company called Coherence which made a distributed cache for the JVM. Confluence used it heavily for its clustered edition, but the original license allowed us to distribute (in inactive form) for free but pay the license fee only when we sold clustered.
Hidden in the license agreement, it said we’d have to pay for every copy _downloaded_ - the implication was this would include 100% of trials downloaded AND any customer who built confluence from source (all paying customers had source code access).
Fast forward - a mad month where we ripped that shit out for about 6 to 8 supported back versions.
This is only for the commercial version, just like one has various paying models for the other Java vendors.
Some companies like to have someone to refer to when their production server goes down instead of online forums.
Business as usual for the open source version, which 80% of the paid development, top of the game GC and JIT compiler, language improvements are anyway done by Oracle, with IBM/Red-Hat, Azul, SAP, Microsoft, Alibaba as main contributors besides Oracle.
> Users of OpenJDK builds from Oracle and users of free Oracle JDK builds are not impacted by the Java SE Universal Subscription
This is somewhat misleading given the history of java and oracles aggressive nature
This applies to java runetime client from Oracle. Which to most users is "java".
If something requires java most people used to be directed to install javase not openjdk
Today if any user of the business downloaded java se from Oracle it triggers and aggressive and often threatening sales process from Oracle
Given that Java SE was Java to most people I think it gives a false impression to say "This is only for the commercial version" even if technically correct
> This applies to java runetime client from Oracle. Which to most users is "java
You are late by a few years. There is no JRE anymore, you are supposed to either use a JDK (e.g. for development) or bundle a small, optimized version of the JDK specifically for your app (see jlink, jpackage for more information).
Google and other search engines can (silencely) put OpenJDKs above javase in the result and we can advocate educators and textbook writers to recommend openjdk (at least point out the difference between the both JDKs) when teaching java to others
This is the second time in as many days that I've seen Microsoft listed as a contributor to Java, but my Google-fu doesn't turn up anything other than announcements that they are building a JVM, and a paper from 1999 about inefficiency in bytecode which led the to opposite of helping Java.
A question in good faith, what has Microsoft done recently to contribute to Java?
So their contributions to the JDK involve buying up someone else and making some proprietary extensions?
Have any of these changes made it upstream or adopted by anyone else?
[Edit] Sister comment points to Java on Arm contributions that Microsoft has done.
There is also JClarity tooling that has been Open Sourced. I would have to take a further look to confirm that this is the case rather than Open to Abandon that some organisations do. Which is still better than leave closed and abandon.
I really love the economics behind Java and how Java is being run as a business that's also a core infrastructure. -- I'm saying this, sounding like a naive fanboy, in the hope that someone will point out the facts that I've missed, or the errors in my thinking.
The way I think about it, Java basically runs on a tax that's being levvied on bigcorps being bigcorps. It's not even really a strict commercial/noncommercial distinction, or an arbitrary line being drawn on any metric like profit, revenue, headcount, etc. It's managers covering their asses. It's compliance considerations that only become relevant when you have lawyers running the show. ...otherwise, I don't understand why anyone would ever pay for commercial Java support contracts.
Let's say you actually are a huge corporation, but you're more enlightened than a typical bigcorp. You might look at those millions that you're giving to Oracle and think to yourself: Hey, this is enough money to enable me to pay a whole department of programmers to look after my interests in the Java ecosystem in a more direct way than Oracle would if I gave that money to them... So, then: Why not do that? Java's open source nature and the OpenJDK process presumably allows you to do that. (Or am I missing something here?)
And at the end of the day, that tax on bigcorps ends up funding Java as an open source effort, with value trickling down to all those other Java users like hobbyists, private individuals, academics, startups (regardless of size and profitability) etc. who can't or won't pay for a piece of infrastructure like that.
This is markedly different from other commercial programming language ecosystems. Take Borland/Embarcadero for example, where they expect you to pay a rather steep price if you're using their tools, regardless of whether you can afford them.
Or take Microsoft, for example, where their whole programming language and tooling ecosystem only exists to support their platform serfdom, and they're giving a very rough deal to their developer-serfs. With Java, you as a developer are actually either the paying customer or an important business partner to Oracle who helps them get to paying customers. Not so with Microsoft. They can take paying customers for granted. They don't get more money if more Windows software gets sold to those same customers. (Don't know how much money they make through commissions on sales of Windows software through the Microsoft store, but I'm willing to bet it's dwarfed in comparison to what they make on Windows licensing). So they engage in trivial innovation, giving a face lift to their platform every few years, coming out with one half-baked GUI toolkit after another, which never reach maturity before being abandoned. That's a horrible developer experience, and horrible economics for their developer-serfs.
Another way that things can go wrong, but don't with Java: Where Java takes from the rich and gives to the poor, many other open source efforts have the problem that they end up taking from the poor and giving to the rich. -- See the debate about elastic search where you have a small open-core startup building something, and then Amazon coming along and charging customers for their repackaged version of the product, without passing any of those proceeds along to the creators of the software.
To make things even better: Take what I've written above and substitute "Open JDK consortium" for Oracle, because saying "Oracle" was actually an oversimplification. It's not a single monopolist at the center of all this, but if you don't like Oracle, you can get your support contract from other commercial (e.g. IBM) or non-commercial (e.g. Eclipse foundation) players.
The customer base is very large companies who find having someone to sue reassuring and are likely to be institutionally incapable of running their own fork of java. Seems fine to me.
Well there is also the fact that the openjdk codebase is huge and so even though it is quite well written and documented fixing a bug in the jdk (and especially a bug in hotspot) isn't easy. Although tbh i have no idea how the quality of support is with Oracle.
I worked for one business that had structured their company structure to reduce the costs of some revenue and employee count licenses. I doubt any one would bother for Java, but still if you need to lower costs, then just put your java division in a separate company.
tl;dr: Oracle now is going to charge you *per employee*, NOT per employee actually using Oracle Java SE (employee = full-time and part-time employees and agents, consultants, and contractors). Frankly I don't even know how that's legal but based on how many lawyers Oracle has, assume it is.
I would imagine it’s legal because you can charge however you want for most products. No-one is forced to buy it though, and the best solution to predatory pricing is not to buy the product.
Yep. And which is better for the customer can vary on the circumstances. I worked for a company that licensed its software both ways (depending on the customer), although as a disclaimer I was a software eng, not in sales.
One thing I'll caution: it's a mistake to think the per-user rate would necessarily be the same in both cases. The business tries to price its software based on value added. IIRC, in the rare cases that we offered customers the choice of pricing method, the final price was (estimated) to be roughly the same, with the per-user rate being the variable...
Disclaimer: I haven't read the original article and I don't have any opinion on what Oracle's doing in this specific case as a result.
It'll take a small amount of HR wrangling for the bigger customers to restructure their businesses to place the Java Developers in their own company that pays this license.
1. What are the implications for the open source or cleanroom JVMs?
2. What are the implications for JVM-based languages like Kotlin, Scala, Clojure, Groovy, etc.?
Speculation:
Even though, it doesn't apply to the OpenJDK, it still sends a signal that the JVM licensing/pricing terms may change in the future. Unlike other corporations developing PLs/runtimes, Oracle does derive their income from this activity.
It make sense to avoid potential licensing/prcing changes by migrating to the JVM to modern and/or less resource-hungry PLs.
This process already started in the Big Data infra space with projects like ScyllaDB and RedPanda.
This only for Oracle JDK. Oracle provides support for old versions of JDKs. So enterprises who have not updated their old software targeting old versions of JDK need to buy this support.
Yeah Oracle has them in a bind as long as the cost to replace the java codebase is more expensive than what Oracle charges they will keep paying. Most of these are probably my guess old banking and accounting systems. I wonder if any US or other countries different departments pay for it as they could take years to move away from it. Oracle I feel is the company that behaves like a gangster as most of their tactics are similar.
This is just for Oracle's implementation of the JVM which has features and enterprise support capabilities that other implementations don't.
No company has or is ever forced to use it. And no one is going to replace their Java codebase because of this. They will simply swap for a different JVM like many of us did years ago.
Which modern language, Go stuck in early 1990's language design, or Rust that still doesn't have a comparable Web story at enterprise level?
Kotlin that leeches on Java infrastructure for its existence? And papa Google is yet to fully rewrite Android in Kotlin/Native?
C# is an alternative, provided there is an implementation for the desired OS platform. Meadow is the only presence in Embedded without the capabilities from PTC, Aicas and microEJ.
Every language new or old will have cons. However, when the perceived con is financial (yes, I realize that OpenJDK isn’t affected, but as evident in the comments many people still don’t know that, and they will never know given all the choices); you’re going to lose a lot of future users.
The part I find interesting is how Java is slowly becoming like COBOL all due to a combination of bad marketing and terrible messaging, and a flawed monetization scheme that was obviously rushed with little thought for the long term.
C# seems the obvious choice to me. One can probably compile Java to C# - it might be in the category of regex then fix compiler errors, so economically reasonable to do. Probably similar library coverage for the two ecosystems by now.
That lets one replace the dependency on Oracle, whose reputation is invariant, with Microsoft, who are known to be nice people who won't blow up your world to increase their profits.
Plus the legal team who liked contracts with Oracle can replace them with contracts with Microsoft. The developers who like Java are fairly likely to like C#, what with it being very nearly the same language.
[in case the subtext is somehow missed, I believe this will punt the problem down the road until Microsoft do something similarly expensive to you]
Microsoft is hardly much different, and contrary to Sun/Oracle once upon a time the gatekeeped .NET features behind different support levels on Visual Studio, like contracts, nowadays gone because obviously the adoption wasn't that great.
There are also some tooling features like code coverage, live testing or byte code rewriting tooling that require Visual Studio Enterprise licenses.
IKVM and J# were two ways of running Java code on .NET.
Not really no, you can't just ignore the culture context of languages.
Ruby projects are going to have a better testing coverage and culture in average than Python projects whereas in reality both languages could do the same.
Java overengineer culture is still present despite being non-existent in other languages like Go whereas in theory it could exist in both.
Nowadays you can do anything with any language, in practice the culture often goes in the way
Ruby is hardly a thing in enterprise computing, and until AI craziness, the only thing that Python mattered for enterprise shops was system administration instead of dealing with a mess of shell scripts and Perl.
Go culture has brought us YAML spaghetting and kubernetes madness at enterprise level.
Many of the features in modern Scala and Java don't exist in other languages.
I would appreciate if you could name them but I would understand if you didn’t have them handy to name. It’s unreasonable to expect you to know them off the top of your head.
* AWS Corretto: https://docs.aws.amazon.com/corretto/latest
* Azul Zulu: https://www.azul.com/downloads/?package=jdk#download-openjdk
* Eclipse Temurin: https://adoptium.net/temurin/releases
* IBM Semeru: https://developer.ibm.com/languages/java/semeru-runtimes