I don't think that you wanted to open this issue on this project, INFRA is all about infrastructure running jenkins project.
Is you issue related to https://github.com/jenkinsci/jdk-tool-plugin?
Maybe Devin Nusbaum can help on this?

To give you an idea, on ci.jenkins.io, we set jdk11 to:

• https://download.java.net/java/ga/jdk11/openjdk-11_linux-x64_bin.tar.gz
• https://download.java.net/java/ga/jdk11/openjdk-11_windows-x64_bin.zip

Yes, Oracle's JDK 11 license change is problematic for most users.

If I had time, I would like to switch the plugin to using OpenJDK builds from this page: https://jdk.java.net/archive/ (although that might not have the most current version of each release?). We would need to update the crawler to look in the right place, and change JDKInstaller.java to accommodate, but I do not think I will have any time to work on this in the near future.

That said, the only reason this installation method exists in the first place is for backwards compatibility. It is unreliable and can break any time Oracle's website is updated (see JENKINS-47448 for an example of when this happened), and OpenJDK does not provide binary downloads for JDK 8 or older, so users building against old versions for whatever reason will be broken if we switch to OpenJDK.

My recommendation would be to install the JDK on your build agents in advance instead of installing it on-demand using Jenkins. If you really need to install it on-demand, then it is better to use something like the "Run a shell command installer" with a script that runs apt-get install openjdk-11-jdk or similar to make sure you get the latest updates.

We had a discussion about this issue in Platform SIG. I have tentatively added it to the Java 11 EPIC for consideration.

My proposal would be to rename the plugin to "Oracle JDK Installer" and to mark it as deprecated for now. I do not think there is a pressing issue to provide a ToolInstaller replacement for OpenJDK which also has weird distribution policies starting from Java 11. Maybe the best way is to add AdoptOpenJDK installer or something like that

I am quite OK with this not getting fixed. The main problem is really the confusion ('java.sun.com' in Installer name, no Java 11 appearing, Java 10 install failing, ...), not that there is no download installer available OOTB. It's simple to install the tool in another way.

While I get your position guys, I think it's really a shame if that plugin disappears

In my company, we have half a dozen of main projects, each one with its own rythm and most of all its one constraints. For example, for every installation or major upgrade in production of one of them, the whole software has to been checked (including third party librairies used, the embedeed JVM, ...) so it is unimaginable to change the JVM, even for a minor update, just because today is sunny

Having this plugin, each team can specify, in its pipeline, what version of Java they want (8, 10, ...)

Installing the JDK on the agent force builds to use it, and remove the choice to teams. Unless I am missing something ?

> Installing the JDK on the agent force builds to use it, and remove the choice to teams. Unless I am missing something ?

It depends on what you understand under "agent". For containers/images it is not a problem, they can be provisioned on-demand.For classic types of agents you are still able to install multiple Java Versions and then just use another ToolInstaller to set path, e.g. to a shared directory.

> I think it's really a shame if that plugin disappears

We welcome all contributions to the project. If somebody steps up and maintains the plugin, it will be a benefit to everyone.

> For containers/images it is not a problem

you're right

> For classic types of agents you are still able to install multiple Java Versions and then just use another ToolInstaller to set path, e.g. to a shared directory

I have more this one in head. I can do this, but it's much more simpler to declare a tool in Jenkins tools configuration, provide a variable in my shared global pipeline lib, and let teams pick the one they want

> We welcome all contributions to the project. If somebody steps up and maintains the plugin, it will be a benefit to everyone.

I know how open source works  and be sure that every contribution I can do at my level, I do.

Here I am a little bit lost ... For the crawler, can I open a PR on it ? It is Jenkins own INFRA, not (directly) used by jenkins installations. And about weird distribution policies, what is the problem ? If we fix the plugin to supports JDK 11, it is ok or not ?

Here I am a little bit lost ... For the crawler, can I open a PR on it ? It is Jenkins own INFRA, not (directly) used by jenkins installations. And about weird distribution policies, what is the problem ? If we fix the plugin to supports JDK 11, it is ok or not ?

Yep, the crawler runs on Jenkins Infra, and it publishes this file, which is then downloaded by Jenkins instances which use it to know what JDK versions are available and what their download URLs are. I think you should be fine to open a PR against the crawler, although you would likely need to synchronize it with a PR to https://github.com/jenkinsci/jdk-tool-plugin, and depending on the changes required you might need to publish a new file instead of the old one so compatibility with old instances is not broken (for example if you switch to AdoptOpenJDK).

Thanks Devin Nusbaum will try

JDK10 is still available, but the plugin now has the wrong URL for it. Per the issue I've just opened, first part of the URL should be:

http://download.oracle.com/otn
instead of:
http://download.oracle.com/otn-pub

Can we get this corrected?

> Can we get this corrected?

AFAICT https://github.com/jenkins-infra/crawler/blob/master/jdk.groovy#L27-L42 needs to be corrected. Somebody needs to propose a PR against this repo and then to test it

I think we need to do something about that for the GA release

https://github.com/jenkins-infra/crawler/pull/79 removes listing of Java 10 in the tool installer

We are most probably not going to be able to propose Oracle JDK anymore for automated downloads after the crawlers. People willing to still do that will be able to do it on themselves.
I think the remaining question is to decide if we use https://openjdk.java.net/ or AdoptOpenJDK. From a licensing perspective, I think this is very similar if not the same.
We'll probably decide also depending on the easiness using one or the other.

Baptiste MathusHave you considered my proposal in https://github.com/jenkins-infra/crawler/pull/79#issuecomment-448178604 ? Closing this one and creating new one for JDK 11?

Yeah, TBH I do not really care. Given the title here and the discussion, using this report to actually fix would also make sense.

I am thinking about a separate issue, because it looks reasonable to have OpenJDK Installer as a separate plugin (and to rename the existing one to the Oracle one)

Given the understandable lack of enthusiasm to keep automatic JDK installers up to date I'm wondering about another option.  I'm planning to move my Jenkins install to run from a Docker container and there are repository images for OpenJDK's JDKs.  Has anyone thought about the easiest way pull one of the OpenJDK images and then use that as a volume to attach to a Jenkins container?  Then you'd simply configure jenkins to use the JDK in the given path and upgrading the JDK patch level would be about as simple as doing a pull for the updated image.

The trick here is that you can use a Docker container as a volume, but not an image so you'd have to pull the image, create a container from it, then create the Jenkins container with that volume attached.

I'm actually not sure about the title of this issue, specifically  "Oracle JDK 11 is not free".

I thought that it was not free for use in production, but that it can be used to produce development builds? If that is the case, as long as the Oracle JRE is not actually being used to run the code in production (rather than just build the JAR file that will ultimately be used), is  there an issue with using Oracle JDK 11?

It's a little academic in my specific case anyway, as we've started using OpenJDK java 11 build now (via the custom tool plugin rather than the JDK tool one - see  JENKINS-55482 ). But I am interested on whether my interpretation of this is right. 

More and more inclined to say this feature anyway was nice for demos, but for real usage should not be used. Because it means your internal servers are constantly downloading binaries from outside.

• It can end up with your company network being banned for excessive bandwidth consumption
• in case of public network glitch, all your builds start to die

Files downloaded from oracle.com are cached in a folder on the master (~/cache/jdks) ...

Maybe you can ask the community if this feature is used / usefull or not.

Given your comment, I think we are talking about two different things: this plugin allows people to:

• either use a pre-filled combo, select JDK, and have Jenkins automatically download it from oracle.com.

• or the other way (which should the strongly recommended one [1]) is to do it very similarly, but define the JDK name, a custom URL (usually pointing to some internal webserver, ideally some binary repository like Nexus or Artifactory where you'll have uploaded some jdk.zip yourself), and then from a Jenkins user standpoint it looks absolutely the same.
  The huge difference is that using the latter strategy you don't risk to block your whole build infra because your Internet access has a temporary network glitch, or a more durable stop if oracle.com starts banning your IP, after getting annoyed that you keep downloading the same thing dozens or hundreds of times a day from their servers (bandwidth does cost some money ).

I hope this clarifies.

[1] Unfortunately, I didn't check, but I don't think this is currently correctly documented. We should be able to fix this soon I hope. (PRs welcome, though . Happy to help anyone doing this).

Baptiste Mathus I added this warning when I split the plugin from core, but it could probably be updated to be more accurate and put in a more visible location so that you don't have to click into the help text to see it.

Devin Nusbaum awesome! Yes, so then I guess we'll see possibly just make a pass to see if/how we can make this even more visible. But that's already great. Thanks!

An installer for JDK from AdoptOpenJDK would be a welcoming addition.

The Oracle OpenJDK 11 LTS builds will only receive updates for 6 months, while AdoptOpenJDK will commit to providing builds until LTS EOL.

OpenJDK provides a new feature release every six months, and a maintenance/security update based upon each active release every three months. We will follow this schedule for publishing binary releases from AdoptOpenJDK to ensure you get the latest, most secure builds.

In addition, every three years one feature release will be designated as the Long Term Supported (LTS) release. We will produce LTS releases for at least four years. This assurance will allow you to stay on a well-defined code stream, and give you time to migrate to the next, new, stable, LTS release when it becomes available.

Though we still need the Oracle JDK Installer, for those who still use an older JDK.
We have some legacy application using JDK 1.6 and JDK 1.7.

I like Baptiste Mathus suggestion of Using a repository manager like Nexus to get the JDK. Then you could get the JDK from your preferred source.

https://api.adoptopenjdk.net is the location you want to pull in versions via our API.  Let me know if you have any issues.

Changed to the "Improvement" according to the discussion

I've created an installer plugin for AdoptOpenJDK: https://github.com/jenkinsci/adoptopenjdk-plugin

The initial release is still pending though as crawler metadata is not updating: INFRA-2111

I have also opened a [PR|https://github.com/jenkinsci/jdk-tool-plugin/pull/5] that adds a warning text to the Oracle JDK installer about the license change and I've also opened a [PR|https://github.com/jenkins-infra/crawler/pull/82] that restores Java 10 and adds Java 11 and Java 12.