Temurin-build: Provide "minimal"/"headless" JDK tarballs

[oakad]

Presently, the binary release tarballs are full featured, but rather big. However, modern java use cases do not necessarily require all the functionality provided; even more so, the extra functionality can be seen as detrimental in server/container setup.

It will be very useful to also have a "minimal" release tarball:

1. No debuginfo in lib
2. No desktop and related components
3. No deprecated components (Nashorn, Corba, etc)

The resulting tarball will be around 80MB in size vs 380MB currently (if my estimate is correct) and will be most useful for:

1. Headless server environments
2. Containers
3. Bootstrapping source builds elsewhere :-)

From my biased perspective, use cases 1 and 2 probably constitute the majority of Java deployments these days, by JVM count (with desktop apps being a minority, whereupon some bigger desktop apps ship with built-in JDK anyway).

[karianna]

@oakad Agreed, you may also want to look at our openjdk-docker project where similar work has been done for minimal docker builds.

[oakad]

I did a cursory glance and thought to myself that you've probably had the minimal builds already. But it still will be nice to have them as plain tarballs, for cases where docker is not in use (or in use, but in some sort of custom way).

[oakad]

I have made some builds (on Gentoo) with JVM variant set to "minimal" and "--enable-headless-only=yes" in configure. The resulting jdk tarball is 106MB on amd64, when stripped of debug info and source pack and compressed using xz.

Suppose, going below that will require some jlink magic post build, as Openjdk's configure refuses disabling things.

[RobGries]

Where can I find headless builds of OpenJDK8 for Linux aarch64?
The currently available builds seem to be not headless and have dependencies for xorg.

[M-Davies]

@karianna What is the status on this?

[aahlenst]

As far as I know, it is currently not possible to offer truly headless variants. Even on most Linux distributions, although they call their variants headless, they are not really headless.

For the tarballs, it do not see the need to strip those down. Everybody can do this themselves as they wish (rm -f src.zip for example). There are no restrictions, except maybe on macOS where everything's signed and the removal of components may introduce breakages (I don't know).

The story is different for OS packages or containers because modification is not so easy. We have stripped-down containers and for the Linux packages, I'm considering splitting them up so for example the jmods become optional. But this is complicated because I'd need to identify what JDK components depend on the jmods and be able to separate them.

For all other needs, there are JREs, jlink and we have jlink.online.

To sum up: I do not see the need to do anything here. Especially, because the JDK is primarily for developers, not for deployments. If anything, we could document what is optional and what not.

[M-Davies]

Thanks @aahlenst . This can probably be closed in that case

[forresthopkinsa]

Do I understand correctly that I'm misusing AdoptOpenJDK by using it for a JRE repository?

[aahlenst]

@forresthopkinsa I don't understand your question. Could you please elaborate?

[forresthopkinsa]

Well, the original question was about minimal/headless packages, and the question was closed with the explanation that the JDK is never minimal.

the JDK is primarily for developers, not for deployments

So I'm getting the impression that the packages labeled "JRE" in the AdoptOpenJDK repositories aren't really meant to be used outside of development.

[aahlenst]

Well, the names are different, so it's likely that the JRE and JDK are two different things, right? 😁

The Java Runtime Environment (JRE) was the trimmed down variant of the JDK for deployments for Java 8 and earlier. When I remember correctly, there were even multiple profiles that resulted in JREs of different sizes. But over time it became apparent that this approach wasn't flexible enough so the Java Platform Module System (JPMS) was invented and introduced with Java 9. One of the objectives of the JPMS was to allow to generate targeted runtimes of minimal size for each deployment. Those runtimes would only include the modules (parts of the JDK) that were really needed. Because each runtime is application-specific, the runtime becomes a dependency of the application, making system-wide installations unnecessary. It's even possible to have multiple applications with completely different JVMs on a single system. This is a totally different model than the JRE. Therefore, the JRE was deprecated and developers instructed to generate application-specific runtimes with jlink (and later jpackage) using their local JDK. But not everone can or wants to do that. That's why we're keeping the JRE around (broken since 14) and are even going to replace it sometime in the future (sorry, we're slow).

Long story short, using the JRE (and whatever comes after that) is fine. But you should really look into jlink/jpackage for new applications. And it's probably clearer now why trimmed down JDKs are a misguided idea for a general-purpose offering.

[forresthopkinsa]

Cool, I didn't know all that about the new module system. I'm still stuck in Java 8 world, which means I'm also still using the old JRE system. I thought AdoptOpenJDK might provide a good Java 8 JRE for Debian Buster but it looks like there's no headless version, which is how I ended up here.

Anyway, thanks for the explanation. I'll just use the Oracle binaries then.

[aahlenst]

Our binaries (JRE and JDK) are as headless as anyone else's. They don't pull any Xserver or similar dependency in and work flawlessly without any screen.

https://packages.debian.org/buster/amd64/openjdk-11-jre/filelist shows what the non-headless package of Debian contains. It's almost nothing. Everything's in the headless package.

[forresthopkinsa]

When I dry-run installing adoptopenjdk-8-hotspot-jre, it prints these dependencies:

java-common libasound2 libasound2-data libxi6 libxrender1 libxtst6 x11-common

[aahlenst]

@forresthopkinsa What is your question? Linux package questions are better taken care of at https://github.com/AdoptOpenJDK/openjdk-installer/issues.

[forresthopkinsa]

Well, that dependency list is why I'm in this thread in the first place. It's pulling in X packages. Are you saying that the Debian package is depending on more than the binary needs, so it's something to take up with the installer team?

[aahlenst]

Java does not work without X11 libraries. That's why Debian's openjdk-11-jre-headless depends on libx11-6, too. This is the full list of our dependencies:

https://github.com/AdoptOpenJDK/openjdk-installer/blob/04546171090d02e9ed5a9811b5d107c7f3f88f0e/linux/deb/config/jdk-8-hotspot-jre/dependencies.txt#L1-L10

If you compare that with the list of Debian's headless package linked in the previous sentence, we actually pull in less.

[forresthopkinsa]

Gotcha. I didn't see any X packages in Oracle's Server JRE but it's very likely that I just overlooked it. Sounds good, thank you for the clarification

[aahlenst]

@forresthopkinsa I downloaded the Server JRE from https://www.oracle.com/java/technologies/javase-server-jre8-downloads.html. Libraries that are required by the JRE:

ld-linux-x86-64.so.2
libasound.so.2
libawt.so
libawt_xawt.so
libc.so.6
libdl.so.2
libfontmanager.so
libgcc_s.so.1
libjava.so
libjli.so
libjvm.so
libm.so.6
libnet.so
libnio.so
libpthread.so.0
libthread_db.so.1
libverify.so
libX11.so.6
libXext.so.6
libXi.so.6
libXrender.so.1
libXtst.so.6

There it is, too: libX11.so.6.

[forresthopkinsa]

Perfect, thanks for walking me through this!