-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AppCDS build step with JDK 17 source/target uses absolute classpath #33069
Comments
jerboaa
added a commit
to jerboaa/quarkus
that referenced
this issue
May 2, 2023
This makes the AppCDS feature more portable where the build and deployment paths differ, but are otherwise identical (for example s2i use-case). Closes: quarkusio#33069
/cc @Sanne (core), @aloubyansky (core), @geoand (core), @gsmet (core), @radcortez (core), @stuartwdouglas (core) |
jerboaa
added a commit
to jerboaa/quarkus
that referenced
this issue
May 9, 2023
This makes the AppCDS feature more portable where the build and deployment paths differ, but are otherwise identical (for example s2i use-case). Closes: quarkusio#33069
manofthepeace
pushed a commit
to manofthepeace/quarkus
that referenced
this issue
May 16, 2023
This makes the AppCDS feature more portable where the build and deployment paths differ, but are otherwise identical (for example s2i use-case). Closes: quarkusio#33069
jerboaa
added a commit
to jerboaa/quarkus-quickstarts
that referenced
this issue
Oct 23, 2023
JDK 17-based AppCDS dump uses absolute paths. See: quarkusio/quarkus#33069
jerboaa
added a commit
to jerboaa/quarkus-quickstarts
that referenced
this issue
Oct 23, 2023
fast-jar doesn't work well due to: quarkusio/quarkus#32877 or https://bugs.openjdk.org/browse/JDK-8265602. We cannot use JDK 17 based AppCDS dump due to quarkusio/quarkus#33069 Lets use static dump and uber jar for the demo.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When creating an AppCDS jsa archive Quarkus'
AppCDSBuildStep
class uses absolute paths for the class path when the dynamic archive is being dumped with-XX:ArchiveClassesAtExit=<jsa-file>
. This makes the feature less usable, since on systems where the exact same classpath would be available, yet the absolute path to the jar file is different mapping the CDS archive fails.The JDK is smart enough to handle the relative class path use-case, thus, using relative paths would be the preferred option. Using the older
-Xshare:dump
with classlist file doesn't seem to have that problem.Expected behavior
AppCDS archive usable if JDK matches, classpath matches, yet the absolute path to the jar(s) is different.
Actual behavior
JVM fails to map the CDS archive. Example with
-Xshare:on
so as to provoke a JVM start error when mapping fails:How to Reproduce?
Reproducer
-Dmaven.compiler.source=17 -Dmaven.compiler.target=17 -Dquarkus.package.create-appcds=true -Dquarkus.package.type=uber-jar
(e.g.getting-started
from quarkus-quickstarts)cd target
mkdir test && cp -a app-cds.jsa getting-started*.jar test && cd test
java -Xshare:on -XX:SharedArchiveFile=app-cds.jsa -jar getting-started-1.0.0-SNAPSHOT-runner.jar
Note that if run from the
target
folder, not the subfoldertest
(i.e. build time identical), using the CDS archive works.Output of
uname -a
orver
No response
Output of
java -version
17.0.7
GraalVM version (if different from Java)
No response
Quarkus version or git rev
6c7268b
Build tool (ie. output of
mvnw --version
orgradlew --version
)maven
Additional information
No response
The text was updated successfully, but these errors were encountered: