On 10/04/2020 17:48, Eirik Bjørsnøs wrote:
I once had the pleasure of debugging a system which after running in
production for a few days would suddenly start returning 404 errors.
Turned out someone (me) had forgotten to specify where Jetty should
unpack its WAR files. So they ended up on shared temp space where a
weekly Centos cron job cleaned them up.
After this experience I pledged to never unpack code to temp again :-)
Also, the performance implications seems not very appealing.
If MultiModuleJARs [1] is re-visited then it would need to explore this
topic a bit more. For now, the only case where the JDK implementation
unpacks is when ModuleFinder.of is created with a file path to JAR file
in a custom file system or to a directory in a custom file system that
contains JAR files. These JAR files might be signed so this is why
JarFile (with the JAR verifier support) is used. It would be possible to
do the verification without support for the JarFile infrastructure, it
just wasn't a priority in JDK 9.
-Alan
[1] https://openjdk.java.net/projects/jigsaw/spec/issues/#MultiModuleJARs
