Should Adoptium be producing Temurin JREs for releases beyond version 8?

[tellison]

We all agree that Temurin 8 should have both a JDK and JRE build available, but what about later versions?

With jlink being introduced alongside modularity, there is a new way to strip down the Java runtime to minimize the delivery in a way that specifically supports the application. Users can also jlink a 'general purpose' runtime environment for multiple applications to share.

AdoptOpenJDK produced JREs and JDKs based OpenJDK 11. Should Adoptium continue this for Temurin, or drop the concept of JREs beyond Temurin 8? This would be a regression for users of the AdoptOpenJDK JREs when moving to Temurin builds.

[sxa]

I think we should ideally give users some warning before deprecating something, however in principle I agree that not providing JREs for 11+ seems "reasonable" particularly if we give people a guide on how to do it themselves, however I think we should probably check with companies supporting the Adopt binaries before finalising such as decision.

[johanjanssen]

We are using AdoptOpenJDK Java 11 Docker JRE images and hope to switch to Java 17 JRE images once/if available.

For us, they're a lot better than JDK's as they're a lot smaller. It's also easy to maintain as we can simply change the Docker image tag once a new minor/major version of Java is released.

I've looked at jlink before, but it's less straightforward. If I look at for instance https://medium.com/azulsystems/using-jlink-to-build-java-runtimes-for-non-modular-applications-9568c5e70ef4 it's still some work to use, especially if the application doesn't use the module system.

Instead of simply using the latest Docker image, we would have to create our own Docker image. Preferably one for each application to have them as small as possible. Then we would have to run the steps every time a new minor or major version of Java is released.

Of course it's all possible and we might be able to automate some parts. But it's still a bigger effort then simply using a JRE. I'm afraid that if the JRE's are no longer available, then people will switch to a JDK or a JRE build from another vendor instead of jlink as it's easier and less maintenance.

Also if I look at the number of downloads (see below) for some of the Chocolatey packages (Windows package manager) I maintain, then I see the JRE is still quite popular.

adoptopenjdk 139288
adoptopenjdkjre 121536
adoptopenjdk11jre 26051
adoptopenjdk11 34622
openjdk8 165571
openjdk8jre 330620
adoptopenjdk8 191632
adoptopenjdk8jre 36497

Of course I don't know how much work it's to maintain the JRE's for Adoptium and if the number of downloads for the JRE are worth the effort. So it's just my 5 cents.

[mbien]

Migration should be fairly straight forward since if image size doesn't matter, passing 'ALL-MODULE-PATH' to jlink will produce a ~105 MB large image with everything in it. I am sure adopt could post the list of modules somewhere which were used for the legacy JRE so that users could reproduce the same image if they want.

In my experience, maintaining a module list is not very difficult (even for non-modularized projects), because it rarely ever changes. A server app doesn't suddenly start using a desktop module. One reason why its so easy is because you code against your custom runtime, and you test against it. If you are missing a module you will notice it right away and you can add it.

Even if you would like to strip the custom runtime down to a minimum (again for a dusty app which isn't using java modules), it usually isn't very difficult either to get an initial list of modules. jdeps + some greping and you basically have 90% of what you need (i wrote a blog post about this).

The contents of a JRE are not very well defined. For example you could argue that part of running Java 11+ is being able to run JEP 330 single-file source-sode programs. But for that you need javac which was never in legacy JREs.

Although i don't think adopt should just stop releasing JREs for 11, maybe 17+ would be a good time for it if it isn't too late yet.

[rikcarve]

With JRE builds from AdoptOpenJDK we have currently an easy way to produce compliant java docker base images on top of our infrastructure providers base image. While there's a way to build a similar runtime manually (e.g. https://justinmahar.github.io/easyjre/), I guess a lot of companies would have to do the same...
So, I would vote for a Temurin JRE build also for later JDK versions.

[PedroC33]

We chose AdoptOpenJDK as the new Java option for our company and we provide both the JRE and JDK packages to quite a number of users. The reason we need the separate JRE is that the JDK is seen as a security risk on Production Servers. We also apply the Rule of Least Privilege to general non developer users and provide them with only the JRE.
In terms of creating our own JREs we would have to use a "one for all" build.
Likewise my vote is for continued JRE releases.

[mbien]

here is a quickly written dockerfile which builds a custom JRE out of the AdoptOpenJDK 11 docker image (only an example, don't copy the JRE into home)

FROM docker.io/adoptopenjdk:11-jdk-hotspot AS builder
RUN jlink --add-modules ALL-MODULE-PATH --compress=2\
 --no-header-files --no-man-pages --vendor-version="[i made this!]" --output /tmp/jdk

FROM docker.io/debian:stable-slim
LABEL description="custom-jre on debian-slim"
COPY --from=builder /tmp/jdk/ /home/jdk/
WORKDIR /home/jdk
CMD [ "./bin/java", "-version" ]

podman build -t debian-custom-jre .
...

podman run --rm debian-custom-jre
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment [i made this!] (build 11.0.11+9)
OpenJDK 64-Bit Server VM [i made this!] (build 11.0.11+9, mixed mode)

podman images
localhost/debian-custom-jre      latest          326797e177c7  5 minutes ago   173 MB
docker.io/library/adoptopenjdk   11-jdk-hotspot  6786c6dbd92b  7 days ago      442 MB
...

[titou10titou10]

I have a few Eclipse-RCP based apps that are packaged with the JRE (currently v11), so they can be installed/deployed very easily without any extra dwnloads for the user (And I can control the packaged version of Java too..).

Using the already packaged JRE directly from AdopOpenJDK for this is extremely convenient. Replacing the embedded JRE with the JDK would add tenths of useless extra Mb to the final package

Example app: JMSToolBox

I guess there are also numerous Java apps (not only Eclipse-RCP apps) that package a JRE and not a JDK...

[AppSturz]

Hello Temurin Community,
Congratulations on the first Temurin release!
For us it's like johanjanssen, rikcarve and PedroC33 wrote. We chose Adoptium / Temurin because AdoptOpenJDK supplied JREs and we don't want to build them ourselves. We see the same security risks on production servers if we use a JDK there.
I would also vote for Temurin JRE builds, also for later Java versions beyond 17.

[Hr0bar]

Yes, this feature is used by many. If you handle many apps its an annoyance to setup automatic jlink and CI/CD for the custom JRE generation only to save tens of MB of space which does not bring enough benefits while adding additional complexity to the project/CI/CD. Also regular AdoptOpenJDK should have been providing JDK builds in parallel until Adoptium is fully online. Such a bad time to switch when there are new releases to be made. BTW AdoptOpenJDK page links some 11.0.12 builds to 11.0.11 files now, so bit of a mess there.

[karianna]

adoptium/adoptium#64 - In short we'll start producing Java 11 and 16 JREs, but from 17 we're taking that toy away ;-). We'll naturally provide lots of guidance on what you should be doing with jlink going forward (you really will thank yourselves once it's done :-D.

[tresf]

Quoting a message I sent to slack:

Of course we could switch to jlink, but I still find it a bit of a hassle to setup everything. I’m afraid many developers won’t invest the effort and instead switch to a JDK.

jlink is a packaging decision. JRE vs. JDK is a runtime decision, e.g. “Where do I get my runtime already installed on the PC” decision.

In my opinion, they’re not really directly related. The question should be:

1. Is the JRE so significantly smaller that it’s warranted to be offered as a download?
   
   Probably “Yes”, it’s less than 1/3 in size!
   
   
2. Does using the JDK instead of the JRE provide compatibility issues?
   
   The answer to this would depend on how the JRE is located for a particular app.
   
   
3. How much effort is it for the Adoptium team to keep providing both for eternity?
   
   I don’t have this answer, but Adoptium team does. 🙂
   
   

I see a lot of mentions of jlink but I’ve been working on a JLink-based installer for months (happy to provide a link to the PR!). It’s a nightmare to get just right on all platforms. jpackage isn’t the answer either, but I find these to be separate discussions that are more about bundling versus using a preinstalled version. It’s only related because jlink passes the JRE burden off to the developers, but the JDK versus JRE argument is more about those bullets above. (edited)

[tresf]

Also to add some "What are others doing" narrative:

• Homebrew - installs entire JDK
• Ubuntu - offers JDK and JRE separately
• Zulu - Only offers JDK
• Bell-Soft - Only offers JDK
• Amazon - Only offer JDK, except on Linux

So from a culture perspective, it seems like this is fairly well accepted by the users.

[keithc-ca]

I was surprised that no one mentioned https://jlink.online/ (see https://github.com/AdoptOpenJDK/jlink.online/). Is the effort being continued at Adoptium?

[sxa]

I was surprised that no one mentioned https://jlink.online/ (see https://github.com/AdoptOpenJDK/jlink.online/). Is the effort being continued at Adoptium?

jlink.online is a great alternative of couse, other than for JDK8, and that would likely form part of our recommendations assuming we switch off production of JREs from JDK17

[tresf]

I was surprised that no one mentioned https://jlink.online/ (see https://github.com/AdoptOpenJDK/jlink.online/). Is the effort being continued at Adoptium?

Thanks for sharing, I didn't know this existed however I still feel this is strongly off-topic, quoting:

jlink is a packaging decision. JRE vs. JDK is a runtime decision, e.g. “Where do I get my runtime already installed on the PC” decision.

Simply put, rarely would an "end-user" that wants a runtime uses an online services like this. This "release" topic is about downloadable runtimes. Custom runtimes are fantastic and useful service. Services which promises to automate this are a neat tool to have, but NOT one which I'd ever be directing users of a particular application towards.

[keithc-ca]

jlink is used to produce both the 'JDK' and 'JRE'. That one or the other is a suitable runtime depends on the set of modules required by an application.

[tresf]

jlink is used to produce both the 'JDK' and 'JRE'. That one or the other is a suitable runtime depends on the set of modules required by an application.

jlink's intent is to create runtime (i.e. "JRE") images, quoting oracle (dot) com:

jlink

You can use the jlink tool to assemble and optimize a set of modules and their dependencies into a custom runtime image.

Regardless, it's a developer tool. As an example.... Let's say you're running a Minecraft server, one requirement is a pre-install Java Runtime, Microsoft doesn't offer one with the server version of the software. You're faced with the following decisions from Adopt's website currently:

• Do I download the JRE?
• Do I download the JDK?

... in the case of most Java applications, either path will result in a running Minecraft server.

The moment you've introduced jlink into the equation, you're talking to a different audience of users. Instead, jlink is what Microsoft developers can chose to use to bundle the runtime components with the server installer. It's simply not a typical end-user decision, so mentioning it over and over is largely off-topic to the OP's question (despite @tellison mentioning it by name).

[johanjanssen]

Also to add some "What are others doing" narrative:

• Homebrew - installs entire JDK
• Ubuntu - offers JDK and JRE separately
• Zulu - Only offers JDK
• Bell-Soft - Only offers JDK
• Amazon - Only offer JDK, except on Linux

So from a culture perspective, it seems like this is fairly well accepted by the users.

Zulu offers JRE's: https://www.azul.com/downloads/?package=jre

BellSoft even offers 2 JRE's: Standard and Full. See for instance:
https://bell-sw.com/pages/downloads/#/java-16-current

[tresf]

Zulu offers JRE's: https://www.azul.com/downloads/?package=jre

Good catch. The default behavior of the downloads page is to apply a filter which filters them out (as well as the FX downloads, etc).

[breun]

With 100+ teams building JVM applications where I work, it is very nice to be able to offer a default JRE Docker image for running these applications in production (and a JDK image for building them on CI). I guess every team could build a custom JRE for their app's custom image using jlink, but that sounds like just more time wasted on CI.

[kyle18th]

We use AdoptOpenJDK JRE image, and also hope that Adoptium can also provide JRE.

[ds2edv]

One vote more for jre

[tushev]

I personally use a JRE and know a lot of folks who use JREs as well.

[Dani-Hub]

We used the AdoptOpenJDK JRE image of both Java 8 (for older applications) and 11 (for all newer applications). Please ensure for Adoptium to follow that tradition for both JRE and JDK as well.

[purple512]

How is not providing JREs even being considered as a possibility? This is insanity. These are end users, they are not going to build their own customized JRE, nor are they going to tolerate hundreds of megabytes of JDK junk that they have no need for.

Just exactly what is an end user supposed to do, in your imagined scenario, when they cannot easily find a JRE download link? I cannot believe this is even a question.

If AdoptOpenJDK goes away without some replacement system in place for downloading a JRE then you have made the Java ecosystem measurably worse.

[tresf]

I've been directing my users to download the JDK for two years. I've never had a complaint on download size, and we have clients all over the world and some on metered connections. The app is downloaded often directly by end-users, 41K downloads since may.

I'm not advocating against it, but I wanted to share a story to the contrary, end users likely install what's asked and don't notice the difference, except for longer download times.

We're moving away from the JDK and towards a jlink produced binary by the year's end. The jlink (not jpackage) effort has been a very manual process and has taken months of work.

[brunoborges]

I am a huge advocate of the deprecation of JRE packages. Here's why:

The primary reason I observe people want to use JRE packages is so that they can have a Java runtime with the entire Java SE platform, but not the JDK tools, and to save storage and download time.

I'd then define benefits as:

• Runtime size on disk
• Download time
• Security (no JDK tools)

Meanwhile, with jlinked runtimes, developers get:

• Much smaller runtime size on disk
• Much faster download time
• More security (no JDK tools, and only a subset of APIs)

A jlinked runtime is, therefore, a better solution than a general-purpose JRE when we look at the criteria for why developers would prefer JRE over a JDK package.

Of course, though, it is a lot easier and convenient to keep the status quo and continue to use general-purpose JREs instead of investing some time into jlink.

And as @tresf mentioned:

The jlink (not jpackage) effort has been a very manual process and has taken months of work.

But is the trade-off not beneficial enough? I do believe it is if we truly value the benefits of a smaller runtime. If developers don't value a smaller runtime with increased security, in exchange for a few months of work to automate jlink, then I don't believe developers truly value these benefits at all.

It is also entirely possible to produce custom Java runtimes that are designed for a category of applications. Let's say your company only deploys Spring Boot apps, but you don't want to have a custom jlink runtime per application. That's ok. If this team is doing things right, it is highly likely that they already have their own base container image. It is then entirely possible to produce a jlink runtime that is general enough to only run microservices.

Note

It is well known that Spring Framework has a dependency on java.desktop module, and this may be the only framework that can't yet benefit from a truly trimmed Java runtime. Hopefully, though, this will be addressed in Spring 6.0 (see spring-framework#26884). Still, a Java runtime for Spring Boot apps can be smaller than a general-purpose JRE.

Multi-Stage Build Containers with jlink

For developers interested, here's how one can produce jlink runtimes without necessarily having to scan modules on every build, as long as you know which modules are required for your app.

FROM adoptopenjdk/openjdk11:latest as jre-build

# Create a custom Java runtime
RUN $JAVA_HOME/bin/jlink \
         --add-modules java.base \
         --strip-debug \
         --no-man-pages \
         --no-header-files \
         --compress=2 \
         --output /javaruntime

# Define your base image. You may use any base OS and version of your choice.
FROM debian:buster-slim
ENV JAVA_HOME /usr/lib/jvm/openjdk-11-amd64
ENV PATH "${JAVA_HOME}/bin:${PATH}"
COPY --from=jre-build /javaruntime $JAVA_HOME

# Continue with your application deployment
RUN mkdir /opt/app
COPY japp.jar /opt/app
CMD ["java", "-jar", "/opt/app/japp.jar"]

[brunoborges]

What are all the modules that are included in the Debian's openjdk-17-jre-headless package? That should be enough for everybody 🙂

"Minimal Java runtime - needed for executing non GUI Java programs, using Hotspot JIT."

Yet, it depends on libasound2 (ALSA), libcups2 (printing), and libfreetype6 (fonts), and it includes all the same modules as the JDK.

If I am not mistaken, all the jre-headless package does is not include the more specific developer tools (e.g., javac).

[MichaIng]

First of all, let me clarify that I do not demand something here. Adoptium is an awesome project, having an alternative, non-commercial source for pre-compiled Java binaries is fantastic, whether it's JRE additionally provided or JDK only 🙂.

It's about ownership and accountability. While it is convenient to have someone else building the Java runtime for you, it is also inconvenient that now too many people rely on such pre-built software and any minor change may break too many people without warning.

It is and should never be your responsibility if anything breaks because anyone uses your free binaries. Everyone who is able to build an own JRE, is or should be perfectly able to decide whether to build an on JRE or using a pre-compiled one. More importantly everyone should be able to decide when/whether to apply an update, read release notes before doing so blindly, running test environments if the production environment is more than a home application, etc. And lastly if someone breaks something by using/updating your pre-compiled JRE, then it is trivial for every individual user to reconsider whether to stay on an older version, use different builds, do own builds or whatever. But this is not your responsibility but the individual responsibility of the ones who use your builds.

I am personally not thinking at all about users who are able to build their own Java, but I'm thinking about the private person who wants to run its own Airsonic, Komga, whatever home server for self-hosting and remotely access media on a private server (just an example), who simply downloads a jar or war and needs a java binary to execute it, but doesn't even know what development headers are. Debian and other non-rolling release distributions ship naturally outdated Java versions, which are supported by Debian packages, but not necessarily supported anymore by upstream software, like the mentioned ones. The other way round, sometimes one requires an older Java version than the one shipped in the used distro version, e.g. due to the radical Java version requirement cut with Minecraft v1.17 and similar cases.

Of course the JDK works just as fine, so it is mainly about reducing traffic and disk space.

Meaning that a general-purpose Java runtime from vendor X may not be necessarily equal to the Java runtime of vendor Y until such specification is written.

Why thinking so complicated 😄? Of course you simply ship the same JRE that is included with the anyway compiled JDK, not more, not less, that is what everyone would expect form it. Basically the current JDK archive(s) could be taken, compiler and packaging binaries, development headers and jmod stuff removed, and viola 😄. No need to overthink whether it is sufficient or perfect for every case, as such does not exist and no one expects it either.

I'm not sure about the definition of a "standard" JRE, but of course there is one, probably java.se, as there are millions or Java applications out there which do not state more than that they require a Java JRE version xy - nm, without any note about a specific build or extension or whatever, and I never faced a case where any of those jar's or war's wouldn't run on the Debian JRE package + Zulu JRE + AdoptOpenJDK JRE (that time) just fine the same way. But as said, do not think about this at all, just take the JRE that is included in the JDK builds, that's it.

[brunoborges]

I'm thinking about the private person who wants to run its own Airsonic, Komga, whatever home server for self-hosting and remotely access media on a private server (just an example), who simply downloads a jar or war and needs a java binary to execute it, but doesn't even know what development headers are.

It is the project's fault if the end-users have no idea what Java is and the project does not document how to get Java installed. This falls under the charter of the project that depends on Java (e.g., Airsonic, Komga, etc). If there is no JRE available out there, or these projects don't want to produce a Java runtime by themselves for their own projects (and heck, simplify the life of the end-user so they don't have to know what Java is and how to install it), then at the very least these projects should instruct user on how to to have the JDK installed.

Basically the current JDK archive(s) could be taken, compiler and packaging binaries, development headers and jmod stuff removed, and viola 😄. No need to overthink whether it is sufficient or perfect for every case, as such does not exist and no one expects it either.

Now someone needs to maintain and be careful what is removed/included in every release (major and minor). There is a cost in software development to maintain the status quo.

I'm not sure about the definition of a "standard" JRE, but of course there is one, probably java.se

As I said in previous comments, there is no definition of what constitutes a standard JRE, and most real-world Java applications wouldn't work with just java.se.

But as said, do not think about this at all, just take the JRE that is included in the JDK builds, that's it.

There is no "JRE" included in the JDK. There is only 'the JDK'.

[MichaIng]

I didn't say that I'm talking about users who do not know what Java is, but users for whom it is not trivial to compile Java, respectively have no experience with building/compiling software in general, for whom the live would be easier if there was a pre-compiled Java (JRE) build to run their chosen Java software.

It isn't a problem to install Java, if no specific version is required, or, thanks to Adoptium, the JDK is perfectly fine, even when development tools and headers are not required. It would be simply beneficial for traffic and disk space to have a simple way of downloading a specific JRE version, independently of the OS/distribution used. Adoptium could do this, just like AdoptOpenJDK did, but of course it is your choice and no one cam blame you for deciding against it.

Now someone needs to maintain and be careful what is removed/included in every release (major and minor). There is a cost in software development to maintain the status quo.

How is this different for the JDK? You don't need to be additionally careful for JRE, just apply the same decisions for JRE that you apply for the JDK builds already, this is what I wanted to make clear. The JRE (runtime libraries and binary) which is in fact already packaged with the JDK archives is perfectly fine and I would be confused if the JRE would contain anything different.

There is no "JRE" included in the JDK. There is only 'the JDK'.

The JDK contains the java executable and the runtime libraries to execute Java applications. This is what I would call the JRE, respectively this is what you can pack to be the JRE. Debian and all distributions who ship both do exactly the same: Usually the JDK package contains the development headers and tools only and pulls in the JRE package as dependency which contains the runtime libraries and binary only.

[sideeffffect]

There are "JREs" provided by some vendors (Azul's Zulu, BellSoft's Liberica and SAP's SapMachine) ( #2683 (comment) )
So what modules are they including and what modules are they excluding? Because the resulting images are significantly smaller.
Confront liberica-openjre-alpine-musl (48.03 MB) with liberica-openjdk-alpine-musl (71.06 MB).

[MichaIng]

On Debian Bullseye it's 353 MiB vs 150 MiB final disk space usage (with all dependencies). Trivial as the JDK pulls in the JRE as dependency and hence whatever decision was made for the JRE applies implicitly for the JDK and the other way round (when it's about the runtime libraries/executable only).

[sideeffffect]

Careful about the situation in Debian. openjdk-17-jre-headless contains a file /usr/lib/jvm/java-17-openjdk-amd64/lib/modules (131,0 MB) and openjdk-17-jdk-headless again contains files /usr/lib/jvm/java-17-openjdk-amd64/jmods/*.jmod (including java.base.jmod, etc) (237,3 MB).

[MichaIng]

Yes, the first as part of the runtime libraries, the jmod's for packing/embedding with Java application (hence development), if I'm not mistaken? The Temurin JDK downloads contain both likewise.

[sideeffffect]

Btw, Alpine's openjdk17-jdk doesn't contain the .jmod files, though (nor do openjdk17-jre and openjdk17-jre-headless).

[MichaIng]

On Debian, openjdk-17-jdk and openjdk-17-jre pull in their respective *-headless packages as dependency. So openjdk-17-jdk does contain the *.jmod files because openjdk17-jdk-headless does. The JRE packages alone do not, as *.jmods are not required for running Java applications.

On Alpine Linux, the JDK package is further split: https://pkgs.alpinelinux.org/package/edge/community/x86_64/openjdk17-jdk

• Sub Packages contains openjdk17-jmods which serves the *.jmod files. Makes sense as Aline Linux is designed to be used as lightweight Linux for e.g. containers, hence a higher need for being able to install smaller parts of the whole JDK individually. Debian has a different focus, though at least it still splits JDK, JRE and the sub packages without the GUI modules and, when it's about disk usage more importantly, their tail of X11, OpenGL and GTK dependencies.

[lukeu]

In the discussion, folks seemed interested in use cases. Here's one I didn't see mentioned:

I create a number of small Java utilities. (Some command-line, some Swing GUI.) I use launch4j to wrap them into a stand-alone .exe so that they're easy to run for non-developers. They are each < 1MB and don't need installing.

This is nice because the wrapper will offer to download a JRE if they don't have one that meets a minimum spec. Since moving to Java 11 I set the download URL to point to AdoptOpenJDK. As long as they set the Oracle registry option, all works nicely & this is just a 1-time download.

Would love to switch to Java 17 (for record if nothing else) and continue to work like this.

(Note: I also understand the desire for bundling specific JDKs: I'm happy if OpenJDK can move faster and break stuff - but not deployed apps. This is good! :-) It makes sense for our main large desktop app. Interestingly we download both the JRE and JDK then hack "jdk.unsupported.desktop" back into the JRE (for JavaFX support) to put in our installer. Why start with the JRE? This just turned out easier, plus we completely failed to get jlink to produce a JRE as small as the "official" one.)

[NPaour]

Hello,
1- I recently created a LibreOffice bug because the Adoptium Temurin JRE was poorly supported.
https://bugs.documentfoundation.org/show_bug.cgi?id=145695
This will be fixed in LibreOffice 7.3
2- I myself provide a Libreoffice package with the Adoptium Temurin JRE integrated.
http://paour.free.fr/libreoffice/index.php
3- We are also writing a LibreOffice recommendation to use the Adoption JRE instead of the Oracle JRE.

Do we have to backtrack?
Nicolas

[brunoborges]

Just wanted to remind that if you are using a custom assembled Java runtime with jlink that does not include java.naming module, you are safe from all these vulnerabilities in logging frameworks.

[tushev]

That's another reason why we need the pre-built JREs from vendor that allow for automatic updates.

In case another such a vulnerability is discovered in Java itself, I doubt that all that folks who assembled their own runtime only because there's no pre-built JRE available (and not because they really need a custom binary), will apply timely updates. Lots and lots of systems hacked, leaked sensitive data etc... 😭

[sxa]

Given the feedback we have received and the use cases described above we have now reverted the decision and have started to produce the Temurin JREs for JDK17 in the same manner as for previous releases as long as it remains technically feasible for the project to do so in the current form. For many simple use cases, using jlink is potentially a better choice as it can produced a customised runtime with only the parts that your application requires, but you now have the option of our JREs.

You can read more about this decision in @tellison's blog post at https://blog.adoptium.net/2021/12/eclipse-temurin-jres-are-back/

Thanks to everyone who has contributed to this issue in recent months :-)