Class Data Sharing

Flags

Class Data Sharing stores class metadata in a shared archive file. The JVM can map that archive at startup instead of parsing, verifying, and laying out the same classes from scratch every time.

Flag details

-Xshare:on

Requires CDS archive use. If the JVM cannot use the archive, startup fails. Use this when you want deployment to prove the archive is valid.

-Xshare:auto

Lets the JVM use CDS when possible and continue without it when the archive is unavailable or incompatible. This is the forgiving operational mode.

-XX:ArchiveClassesAtExit=app.jsa

Creates a dynamic CDS archive when the application exits. This is the simplest AppCDS training workflow: run the app once with representative startup paths, then reuse the generated archive.

-XX:SharedArchiveFile=app.jsa

Loads classes from the specified archive. For application archives, use the same application class path, module path, and JDK build that were used to create the archive.

-XX:DumpLoadedClassList=app.classlist

Writes the names of loaded classes to a class-list file during a training run. Use this for the static archive workflow.

-XX:SharedClassListFile=app.classlist

Reads a class-list file while dumping a static CDS archive with -Xshare:dump.

How CDS works

During normal startup, the JVM loads classes, parses class files, verifies bytecode, creates internal metadata, and links classes as needed. CDS moves a portion of that work into an archive-generation step. Later JVMs map the archive into memory and reuse the archived metadata.

The default JDK already ships with a CDS archive for platform classes. Application CDS extends that idea to application and library classes. This is most useful for short-lived services, serverless functions, CLIs, test workers, and horizontally scaled services where many JVMs start with the same code.

When to use it

Use CDS when startup time or memory sharing matters: command-line tools, build workers, batch jobs, container autoscaling, serverless functions, or dense hosts running many JVMs from the same application image.

It is less important for a single long-running process where startup is rare and class metadata is a small part of total memory.

Java version support

Basic CDS is older than the cataloged releases, while AppCDS became generally useful in Java 10. Default CDS archives are available from Java 12, and dynamic CDS archives are available from Java 13. The Java 25 commands in this recipe use the modern AppCDS workflow.

Related JEPs

• JEP 310 - Application Class-Data Sharing, delivered in JDK 10.
• JEP 341 - Default CDS Archives, delivered in JDK 12.
• JEP 350 - Dynamic CDS Archives, delivered in JDK 13.
• JEP 483 - Ahead-of-Time Class Loading & Linking, delivered in JDK 24 and built on the CDS/archive direction.

Examples

Use the default CDS archive strictly

java -Xshare:on -jar app.jar

Use this when you want startup to fail if the archive cannot be mapped.

Create a dynamic AppCDS archive

java -XX:ArchiveClassesAtExit=app.jsa \
  -jar app.jar --warmup

Run a representative path so the archive captures classes actually used by the application.

Run with the generated archive

java -Xshare:on -XX:SharedArchiveFile=app.jsa \
  -jar app.jar

Use the same JDK and application artifact set that produced app.jsa.

Create a class list, then a static archive

java -XX:DumpLoadedClassList=app.classlist \
  -jar app.jar --warmup

java -Xshare:dump \
  -XX:SharedClassListFile=app.classlist \
  -XX:SharedArchiveFile=app-static.jsa \
  -cp app.jar

Use this when you want an explicit class-list based archive build step.

Verify

• Use -Xlog:cds=info to confirm which archive is mapped at startup.
• Measure startup time before and after using the archive.
• Compare RSS and shared memory when multiple JVMs run on the same host.
• Regenerate the archive after JDK upgrades, dependency changes, or class path changes.

References

See Oracle's Java 25 Class Data Sharing guide and the java command reference.