Investigate shipping smaller deb/rpm packages about installer HOT 3 CLOSED

Headless packages are a good thing in reducing dependencies for server side applications. But they can also make trouble. One example from our work was a server side application whose library needed the Non-Headless libraries only for calculating Font sizes for its generated HTML/CSS.

In OpenJDK the split between Headless/Non-Headless is done by separating frontend Java libraries in own packages (the ones without -headless in the name). And only these packages require the Xorg dependencies for example which make a big difference in size.

AdoptOpenJDK has a lot of libraries bundled while the OpenJDK packages in the Linux distributions depend on distribution libraries. I don't know the AdoptOpenJDK Build process from it's sources but i think these libraries are supplied for (TCK) compatibility. With these libraries AdoptOpenJDK headless packages would stil be bigger than the OpenJDK ones.

The naming convention is also interesting. Actually there is adoptopenjdk-$VERSION-$JVM[-$JRE] where the -jre is optional. It breaks the "explicit is better than implicit" paradigm for a JDK but it works. To not break the actual names the -headless should be optional too. For example:
adoptopenjdk-11-hotspot
adoptopenjdk-11-hotspot-headless
adoptopenjdk-11-hotspot-jre
adoptopenjdk-11-hotspot-jre-headless
adoptopenjdk-11-openj9
adoptopenjdk-11-openj9-headless
adoptopenjdk-11-openj9-jre
adoptopenjdk-11-openj9-jre-headless

from installer.

I took a look in the AdoptOpenJDK 11 lib folder and found these two files:
libawt.so
libawt_headless.so
The headless variant is much smaller. I compared the dependencies and most of the dependencies are the same. But libawt_headless has more dependencies than libawt. And the strange thing is that one of these dependencies is libawt. The other one is even more strange as this is libjvm.

from installer.

Unlikely that we'll do this. It's not something that's supported by upstream, it's a lot of work to untangle everything, and if size is at a premium, users shouldn't use a JDK anyway but rather a jlink'ed runtime.

from installer.