Ancient OpenJDK version as the default?

[ocdtrekkie]

I have some concerns about Microsoft adding OpenJDK 8 into this project as just "AdoptOpenJDK.OpenJDK". Java 8 is very old, and even legacy apps I've seen in production work with OpenJDK 11. I'd recommend Microsoft strongly reconsider continuing to treat Java 8 as the default, especially in a brand new 2020 project. (This would kinda be like installing Word 2013 today.)

cc: @KevinLaMS on this because of #169

#173 adds OpenJDK 14, but starts a whole new nightmare, because the proposed OpenJDK is from a different source than the one a Microsoft employee merged.

Which is to say, this is starting a much darker timeline than the "winget install powertoys" makes me believe is being created. "winget install openjdk" might install an ancient OpenJDK, it might come from a different builder, etc.

[ajoberstar]

I would expect that for something like Java they're going to either use something like the "Release Channels" mentioned in the roadmap or have to provide different packages.

e.g. Many Linux distros provide some variant of openjdk-8, openjdk-11, and openjdk-latest packages to allow people to pick different LTS versions or just stay on the latest feature release.

[ocdtrekkie]

@ajoberstar I would say it's very important they figure that out ASAP during this preview, and decide if Microsoft is going to empower this team to select a "correct" OpenJDK flavor as well. A particular fear I have is that some app installs will take advantage of this new system to install dependencies for their applications, and things like starting off with apps today building an expectation of being served OpenJDK 8 is potentially very bad.

[utybo]

Also, it looks like the specific installer for AdoptOpenJDK that's pulled is using OpenJ9, which might not be great as I've had issues where OpenJ9 was the culprit and the only solution was to use a HotSpot JVM instead.

[JudahGabriel]

FYI, OpenJDK 8 is Google's own recommendation for packaging Progressive Web Apps for the Google Play Store. See Google Bubblewrap Requirements, where they note,

Using a version lower than 8 will make it impossible to compile the project and higher versions are incompatible with the Android command line tools.

[utybo]

Yeah, there are breaking changes and some stuff requires OpenJDK 8. Having both versions 8 and 11 (the current LTS versions) would be great. Apparently, that's already the case with NodeJS, as I can see both versions in the repository. https://github.com/microsoft/winget-pkgs/tree/master/manifests/OpenJS/NodeJS

[ocdtrekkie]

@JudahGabriel That's horrifying but mostly completely unsurprising coming from Google. I believe Android is usually pinned to some very obsolete flavors of both Java and Linux.

@utybo At the very least, the default should be the latest version, and Microsoft should have a clearly communicated strategy for how to manage support of differing versions of software packages. (As obviously, they are well used to doing as they support Office and Windows versions for like a decade each alongside each other.)

However, I would express that package managers tend to be designed to be used in the process of installing dependencies, and people building an app in 2020 should not be using Java 8. So a package manager launching in 2020 shouldn't have much need for archaic versions.

[utybo]

A lot of stuff is not meant to support Java 9+ though, including everything Android and any legacy library that happens to not be automatically compatible with the module stuff Java 9 brought to the table. As I said before, we pretty much need both options here.

Microsoft should have a clearly communicated strategy for how to manage support of differing versions of software packages

I don't think we can blame them too much, this project has literally just been released live to the public :). For the strategy, there's microsoft/winget-cli#147.

This is a preview, so not having everything we need is expected. The Windows Terminal preview was rough, but it became something great ;)

[ocdtrekkie]

@utybo I understand it's a preview, but this seems like a pretty fundamental part of being a package manager, like showing off a car with no engine in it. So as someone very interested in pushing software to Windows PCs for a living, I'll be watching how they handle this particular issue closely. :)

[KevinLaMS]

Thanks for the feedback. I will look into the issues raised.

[utybo]

@ocdtrekkie Regarding this comment you made in the other repo, are you sure about openjdk being a link to the absolute latest release of Java? In my opinion it should link to the latest LTS version (e.g. java 11 right now), because updating openjdk would have... interesting consequences when switching to a new major versions.

• Would it switch to the next version automatically (e.g. remove major version X, install major version Y)? In that case, everything that used the Java installation's path would break, as the installation path has the Java version in it.
• Would it just leave you at your current version? (e.g. you keep major version X but now openjdk points to major version Y) That seems to be the best option but since non-LTS versions don't typically have very long lifespans, it would be better to just point to a stable version X that would be supported for a long time. If you use non-LTS versions, people will just keep using that non-LTS version which would eventually become obsolete.

[omajid]

cc @karianna who is a part of OpenJDK, AdaptOpenJDK, a Java champion and a Microsoft employee (among many, many other things). @KevinLaMS, @karianna is an excellent resource for anything Java-related.

[gdoenlen]

@ocdtrekkie Regarding this comment you made in the other repo, are you sure about openjdk being a link to the absolute latest release of Java? In my opinion it should link to the latest LTS version (e.g. java 11 right now), because updating openjdk would have... interesting consequences when switching to a new major versions.

* Would it switch to the next version automatically (e.g. remove major version X, install major version Y)? In that case, _everything_ that used the Java installation's path would break, as the installation path has the Java version in it.

* Would it just leave you at your current version? (e.g. you keep major version X but now openjdk points to major version Y) That seems to be the best option but since non-LTS versions don't typically have very long lifespans, it would be better to just point to a stable version X that would be supported for a long time. If you use non-LTS versions, people will just keep using that non-LTS version which would eventually become obsolete.

The OpenJDK developers have stated multiple times that there is no LTS version. There are versions supplied by vendors that may be LTS, but those versions have nothing to do with OpenJDK project, and those versions may be arbitrary (one vendor may choose to make JDK 13 their LTS, and another version 9).

[ajoberstar]

@utybo While people will often stick to LTS in production, it's not inherent that "everything would break" when you switch major versions. Sometimes you need dependency updates, rarely a deprecated feature may have been removed, but I have a lot of code that can keep up with the latest JDK version without any issue.

Fedora provides a package java-latest-openjdk that provides whatever the most recent feature release is, which is entirely stable, it's just going to be superseded by the next feature release in 6 months. Providing any easy way to stay current would be great.

For my own personal needs, being able to side-by-side keep all active LTS versions and the latest current is important.

[ocdtrekkie]

@utybo I think it's an implementation detail for Microsoft to decide, but perhaps rather than have an openjdk package, we should only have openjdk-latest and then openjdk-8, openjdk-11, etc. Such that someone will have to specify their intention if they include "install openjdk" in a script. (Perhaps if you were to just winget install openjdk, winget should tell you what packages it knows about that start with openjdk-?

Java 8 has been unfortunately extremely ossified by legacy developers, but modern Java (and hence OpenJDK) is meant to move more quickly, and developers working with later releases are probably going to have less issues tying to the latest major release.

[utybo]

I was under the impression that some tools (like Eclipse or IntelliJ) which rely on the path (e.g. JDK location configuration) might break -- but that's quite easy to fix so eh.

Also, it looks like OpenJDK in this repository is from AdoptOpenJDK, and AdoptOpenJDK considers versions 11 and 8 to be LTS.

edit: I agree that having openjdk- + openjdk-latest packages might be a good solution.

[ocdtrekkie]

I believe you may be right on 8 and 11 being AdoptOpenJDK's LTSes. Though that brings up the other question in the topic: A Microsoft employee had opened a PR to add an alternative OpenJDK 14 from someone else to the repo.

[ajoberstar]

The OpenJDK developers have stated multiple times that there is no LTS version. There are versions supplied by vendors that may be LTS, but those versions have nothing to do with OpenJDK project, and those versions may be arbitrary (one vendor may choose to make JDK 13 their LTS, and another version 9).

Yet, the JDK 8 updates project and JDK 11 updates project are still officially part of OpenJDK and being actively updated (albeit by RedHat and not Oracle). In practice, there's a consensus around 8 and 11 being treated as LTS, so far. We'll see if that holds when Oracle's next LTS (17) comes around.

In the end, what matters is providing access to the streams of versions a particular vendor is providing. If there's an Azul Zulu OpenJDK package in winget, it should support their actively maintained version streams (8, 11, and current). Same for a RedHat package or AdoptOpenJDK package or Oracle package.

[karianna]

Long thread :-). Hi all, I'm the director at AdoptOpenJDK (disclaimer, I'm also the engineering manager for Java at Microsoft), so I'll add some thoughts from our experience there.

Our download stats at Adopt show that OpenJDK 8 and 11 (which all of the vendors have designated as LTS) have roughly the same market share and so I personally believe both should be made available for developers who need a Java on their developer desktop (that matches what they work on in production).

As Windows is a premier platform for development it's also not unreasonable to offer the latest version (14 today) as developers love to explore new developer productivity!

Adopt has an API which is backed by Swagger usage so you can grab all three of these versions easily. I'd personally recommend the HotSpot builds for the principle of least surprise.

[jamierocks]

I'm still yet to read through all the comments in this thread, but I'd like to inject my view having read some of them.

There are bundles of JDK distributions (Oracle, Red Hat, AdoptOpenJDK, Amazon, etc) these days, and everyone has their choice - winget packages with the author in the identifier, all the major distributions should be supported and packaged. For example, we could have:

• AdoptOpenJDK.OpenJDK (they support Java 8, 11, and 14 according to their site)
• Amazon.Correto (they support Java 8 and 11 according to their site)
• RedHat.OpenJDK (they support Java 8, 11, and 14)
• and more

Multiple versions of the JDK are maintained and supported - principally (at this time) OpenJDK 8, 11, and 14. Again, all of these should be supported - as an example, Red Hat still has OpenJDK 8 as the first listed distribution. This could potentially be resolved either as:

• RedHat.OpenJDK8
• RedHat.OpenJDK.8

Some distributions such as AdoptOpenJDK have variants (such as the actual JVM in use), I'm all for supporting these variants if we can come up with a reasonable way to approach this - though I think we should stick to defaults if not. I find particular issue with the recently merged PR which uses OpenJ9 for AdoptOpenJDK where I would expect AdoptOpenJDK.OpenJDK to use Hotspot.

[gdoenlen]

Multiple versions of the JDK are maintained and supported - principally (at this time) OpenJDK 8, 11, and 14. Again, all of these should be supported - as an example, Red Hat still has OpenJDK 8 as the first listed distribution. This could potentially be resolved either as:

The Scoop installer Java bucket has a good system for this: https://github.com/ScoopInstaller/Java/tree/master/bucket

You can for instance:

scoop install adoptopenjdk-hotspot
scoop install adopt8-hotspot
scoop install adopt14-openj9

[brunoborges]

See these PRs for latest builds of OpenJDK (using installers from AdoptOpenJDK):

1. OpenJDK 11 OpenJDK 11 for AdoptOpenJDK  #408
2. OpenJDK 14 OpenJDK 14 for AdoptOpenJDK #409

[fjeremic]

Also, it looks like the specific installer for AdoptOpenJDK that's pulled is using OpenJ9, which might not be great as I've had issues where OpenJ9 was the culprit and the only solution was to use a HotSpot JVM instead.

Hi @utybo! OpenJ9 committer here. We would love to help with the issues you've had so we can make our JVM more compatible with HotSpot. Would you be open to opening up an issue at eclipse/openj9 repository on GitHub in regards to your problem so that we can investigate?

[jamierocks]

I've made pull requests for both Corretto 8 and 11, see:

• Corretto 8 Amazon Corretto 8.252.09.2 #533
• Corretto 11 Amazon Corretto 11.0.7.10.1 #611