Deployment is bigger than with other JREs

[mlaggner]

I recently switched from the Azul JRE to the JBR JRE and recognized, that my deployment is much bigger than with the Azul JRE.

Hunting down the issue has shown me, that the /lib/modules from your JRE heavily differs from Azul (and also Adoptium, which I analyzed too). It looks like that on JBR the modules container has been built with the parameter --compress=2 (probably here if I found the right script: https://github.com/JetBrains/JetBrainsRuntime/blob/jbr-release-21.0.6b872.80/jb/project/tools/windows/scripts/mkimages_x64.sh#L64) which results in a "slightly" compressed modules container (57MB vs 100MB from Azul/Adoptium).

This leads to another "problem" if you package your final app for deployment (especially with LZMA - I've tested XZ and ZSTD) - the modules can't be compressed any further (57MB from the JRE -> 53MB compressed) while other JVMs (Azul/Adoptium) can be compressed by far better (100MB from the JRE -> 24MB compressed).

Having said this, I also compared the compression of the whole JRE between JBR/Azul/Adoptium (all 21.0.6) with XZ and the best compression algorithm. I know that the JREs differ slightly, but the finally compressed archive should not differ that much. But JBR is by far bigger than others:

• JBR - 69MB
• Azul - 29MB
• Adoptium - 29MB

To get those results, I made many tests comparing different parts of the JVM at all and it looks like LZMA cannot compress the modules any further.

Having said this, I am unsure what benefits the compression of /lib/modules offers beside saving ~43MB of storage (runtime). The drawback here is that the JVM probably needs to extract the container at runtime (performance) and the deployment size is just bigger for many use cases (especially if you plan to re-package the final deployment with LZMA - waste of bandwidth).

[mkartashev]

I'd also check if the modules list is the same (java --list-modules). JRE is not standardized so different vendors may include different sets of modules.

[mlaggner]

You are right - the modules differ:

• JBR - 56 modules
• Azul - 52 modules
• Adoptium - 49 modules

also just from the amount of modules it is hard to compare, so I decided to extract the modules container and compare the uncompressed storage size of the modules too:

• JBR - 189MB
• Azul - 151MB
• Adoptium - 150MB

so yes - the uncompressed modules from JBR are ~ 38MB bigger than the counterpart of Azul/Adoptium. But a difference of 38MB should not be the same difference after being compressed with LZMA!

[mkartashev]

I'm not sure I understand what exactly is the issue you would like to get addressed here?

[mlaggner]

When I use JBR as the JRE inside my app, I see that the deployment is unnaturally bigger in comparison to other JREs. The difference in my deployment is ~40MB (packaged size) which is kinda huge and I just wanted to ask you, if there is a good reason that you packaged the /lib/modules container in JBR the way you do (which is different from Azul and Adoptium).

As I wrote above, the main reason why the deployment is quite different in size is the way you have built /libs/modules. If you do have a reason you packaged this the way you do, everything is good. If you were not aware that this can have some bad influence for repackaging, I'd suggest you to do it like Azul/Adoptium

[ApoloApps]

Hi, any news on this? Im trying to optimize my app's size and this could reduce it a fair amount if turns out to be true.

[mkartashev]

Im trying to optimize my app's size and this could reduce it a fair amount if turns out to be true.

When your application is based on a JRE, it is a good idea to build a custom-tailored one anyway such that it includes all the necessary modules, but does not bring anything else that isn't useful and just wastes space. Start with a JDK and use jmod to build your custom JRE. That's what JetBrains Runtime does.