jar file size doubled between 1.15.4 and 1.15.5
This seems to have been caused by the inclusion of MR's Java 9 variant.
Looking at the pom.xml, it seems the classes just get copied over with their bytecode version updated, which feels very low on bang-for-the-buck considering this adds 4MB for very little (faster validation?) benefit.
Is there anything that can be done to not ship these duplicate files?
It's mainly meant to support CDS which requires stack map frames.
My rationale was that the jar file is a small index anyways, and the class files are only read on demand. So the class file version that is not used just sits on disk and is never read.
Agents that bundle Byte Buddy can shade out, and native images will do so implicitly.
How are you encountering problems with the file size?
We are monitoring our applications' total size and out concern is that these increases can add up.
If every jar took this approach, we'd end up doubling the time of anything that transferred/copied/stored our application (deployment, CI, etc.).
As far as I understand the class files in the "normal" directory are just there to support Java 5? Do you have a plan/timeline to increase the required Java version in the future?
That's true. I hope that CDS will be supported for older class files in the future, there's an open ticket in OpenJDK, and I consider releasing a classifier version that is leaner in the future.
Makes sense! Thanks for the information and thanks for your time!
Feel free to close this issue if you like.
@raphw I couldn't find the issue in the OpenJDK JIRA, do you remember the number?
I see the ticket has been closed: https://bugs.openjdk.org/browse/JDK-8288334
Sadly it has not been implemented, but Won't Fixed. :-/
Yes, I saw that. Let me think about this some more time. I did not really believe jar size would be a real issue since we are speaking of single digit megabytes.
I have full understanding that this would be a problem if everybody would do it, but the background is that Byte Buddy is used in tooling a lot, especially Java agents, where old VMs should be supported. This especially in big businesses that have apps that do no longer get updated and where for example tracing tools would miss important traffic if the apps could not get instrumented. At the same time, modern users have contrary needs and this caters to both. Most libraries do not run in this problem, so this is how we ended up like this.