Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8279366

CDS should allow alternative locations for JAR files in classpath

    XMLWordPrintable

Details

    • b21
    • x86_64
    • windows_10

    Description

      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.

      Attachments

        Issue Links

          Activity

            People

              ccheung Calvin Cheung
              webbuggrp Webbug Group
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: