[makomk]

The "free one" that Oracle refer people to doesn't even come with a Windows installer, nor does it have any useful installation instructions. It's (presumably) intentionally unusable to all but the most persistent and technically knowledgeable users.

[pron]

First of all, the JDK doesn't need an installer. You can put the JDK wherever you like and just point JAVA_HOME to it. Second, the JDK is intended only for developers. We have discontinued the "consumer/desktop JRE", and it is now the recommended practice for developers to create their own embedded runtimes with jlink. We are also working on a tool that would allow developers to package their applications with native OS installers [1]. Third, nearly all OpenJDK contributors are Oracle developers and use those builds, and AFAIK few if any OpenJDK contributors use any other build than the Oracle or the Red Hat ones, and so if you want anyone to fix your bug, you need to report it against an "official" build. Fourth, I don't know why you put free in scare quotes. It is the most popular OpenJDK distribution and it is as free as all the others (because all OpenJDK distributions are released under the same OpenJDK license; they are all owned by Oracle, BTW). Finally, you should ask yourself why is the OpenJ9 JDK, which makes up for maybe 1% of their downloads, featured so prominently on Adopt? Well, the reason is that IBM is in the habit of finding promising community projects, throwing some money and people at them, and taking control. This is what happened with Harmony, what happened with Adopt, and my guess is -- though I have no knowledge of the situation -- that this is precisely what Oracle feared would happen with Jakarta. This may not be bad if IBM also contributed something to OpenJDK, but they don't [2]. They just take over community projects, and then take credit for work that's done by Oracle. IBM taking control over Adopt is also why they lost their TCK license. The TCK is licensed freely for OpenJDK builds but requires payment for non-OpenJDK builds. IBM used Adopt to run the TCK on the OpenJ9 JDK -- not an OpenJDK build -- which put the entire project in violation of the TCK terms. So this entire story should be viewed in this light, as well: we have a company doing nearly all the work an an open source project and other companies wishing to exploit that.

You need to realize that Oracle does over 90% of the work on OpenJDK, and that the Java ecosystem is so big that there are other very large corporations who want to make money off of Java, and so are very interested in painting a picture of a "non-cooperating" Oracle. But again, whether you use a build from Amazon or Adopt, those source code behind those builds is developed and maintained by Oracle developers. And I can also tell you that we beg companies that build distributions or make money off of Java to contribute more, but so far, they can't or won't. We're happy to see Google starting to contribute more, and, of course, we've been cooperating with Red Hat for a long time. But so far, Amazon and IBM contribute little if at all (but I will say again that some companies cooperate nicely with Oracle -- Red Hat, SAP, and now it seems like Google may be starting to do that as well).

[1]: https://jdk.java.net/jpackage/

[2]: https://blogs.oracle.com/java-platform-group/building-jdk-11..., https://blogs.oracle.com/java-platform-group/the-arrival-of-...

[hollerith]

>it is now the recommended practice for developers to create their own embedded runtimes with the JDK tooling

I am unfamiliar with Java and am curious: if I open 2 Java-based apps on my Mac or Windows box, how much of the memory devoted to Java tooling that would have been shared if the apps were built with the assumption that there is a JRE already installed locally is instead duplicated because of the recommended practice that you describe?

[pron]

Very, very little. Applications don't include the whole JDK, but a custom runtime they create with a tool called jlink (I meant that JDK tools, i.e. jlink, are used to create the custom runtime, not that the runtime includes the JDK tools). That runtime is only a few tens of megabytes (smaller than the shared JRE, as only modules actually used by the application are included). Also, the decision to do away with the shared JRE was sort of forced by shifting consumer and OS behaviors, that no longer encourage shared runtimes, but are shifting to containers and app stores. So whether a shared runtime is technically a better approach or not is moot, because the entire software ecosystem is shifting away from them.