A DESCRIPTION OF THE PROBLEM :
I was experimenting with "JEP 310: Application Class-Data Sharing" and "JEP 350: Dynamic CDS Archives" to improve startup performance of my multi-platform Java Swing Desktop application and command-line tool.
It worked on my development machine. It worked on my build machine. Nothing works after deployment. To my surprise, the AppCDS *.jsa (as opposed to the JDK *.jsa generated via java -Xshare:dump) hardcodes the machine-specific absolute file paths (in this case, my build machine) into my *.jsa file, making the *.jsa file not portable (e.g. my app jar might be located at X:/build/app.jar during build and AppCDS *.jsa generation, but will be located at C:/Program Files/MyApp/app.jar after installation).
This severely the limits use cases of AppCDS, effectively to docker where you just ship a pre-built machine, or generating the AppCDS *.jsa after deployment, which is not always desirable or possible.
e.g. java usage after application installation:
"C:\Program Files\MyApp\jre\bin\java.exe" -Xshare:on -XX:SharedArchiveFile="C:\Program Files\MyApp\app.jsa" -jar "C:\Program Files\MyApp\app.jar"
Problem:
If the app.jsa file was pre-generated during build (e.g. with -jar "X:\build\app.jsa") then it won't work after deployment, because the JVM will complain about a classpath mismatch (even though it's the same jar, relative to the same application folder / embedded jre folder).
Proposed Solution:
Please make it so that the expected hardcoded classpath is relative to the given -jar app.jar and make it possible to produce *.jsa files that are not machine-specific,
and don't require the $PWD to be the application program files folder.
Workaround:
During build, cd into the app.jar folder and then call java -XX:ArchiveClassesAtExit -jar app.jar (just the file name, i.e. use relative file path as classpath) to generate the *.jsa to make it portable. However, the caveat here is that it now only works if java is executed with a specific $PWD which is not feasible for command-line tools.