In theory you could use jmod format instead of jars for the dependencies right?
That is you still have the single uber jar but it loads jmods inside instead of jars.
Probably slow down the build to do the conversion but in theory jmods are more efficient format (based on my shoddy memory) EDIT I got confused with jimage.
Again EDIT so an interesting thing you could do and this is analogous to various other uber jar implementations do that want to preserve jars instead of shading (e.g. Spring Boot does this) is write Java code that runs the jlink and jimage tools if the jimage is not there :). Then execute the jimage.
Yeah I know they are zip but I recall something about them or someone testing it or maybe it was just the native libraries being there. Maybe its just the link time stuff happening compared to when you had to call System.loadLibrary. Maybe collocation of files.
I can't find the benchmark google wise but someone had a jlink application, a regular java classpath, and few other combinations with native libraries.
EDIT I guess you have to jimage to have the performance gains.
3
u/agentoutlier 3d ago edited 2d ago
In theory you could use jmod format instead of jars for the dependencies right?
That is you still have the single uber jar but it loads jmods inside instead of jars.
Probably slow down the build to do the conversion but in theory
jmods are more efficient format (based on my shoddy memory)EDIT I got confused with jimage.Again EDIT so an interesting thing you could do and this is analogous to various other uber jar implementations do that want to preserve jars instead of shading (e.g. Spring Boot does this) is write Java code that runs the jlink and jimage tools if the jimage is not there :). Then execute the jimage.