What is Application Class Data Sharing (AppCDS), and how does it differ from default CDS?

Default CDS, enabled automatically since JDK 12, only archives the JDK's own bootstrap classes - it says nothing about the application's own classes or its third-party libraries.

AppCDS extends the same mechanism to cover application and library classes too, so the parsing and verification savings apply to the bulk of a typical application's classes, not just java.lang.*.

Traditionally this required a manual two-step process: run the app once with -XX:DumpLoadedClassList to record which classes actually got loaded, then use -Xshare:dump with that list to build the archive, which had to be regenerated whenever the application's classes changed.

Since JDK 13, with further simplification in JDK 19, dynamic AppCDS makes this far easier: adding -XX:ArchiveClassesAtExit=app.jsa to a normal run automatically captures the classes that were loaded and writes the archive on JVM exit, ready to be reused on the next startup with -XX:SharedArchiveFile=app.jsa.

The practical payoff shows up most in short-lived JVM workloads - CLIs, serverless functions, and frequently-restarted microservices - where startup time is a meaningful fraction of total run time.