P3 Description
Appending to boot class path when using CDS (bootstrap) shared archive should not invalidate shared archive.
========= Test case concept:
# Create shared archive
$JAVA_HOME/bin/java -Xshare:dump
# Use the shared archive, and append any class to bootclasspath
$JAVA_HOME/bin/java -Xbootclasspath/a:./hello.jar -Xshare:on -version
======== Why?
1. Logically, appending to boot class path does not change behavior of classes found within boot class path. It merely extends the class search space. Hence, it should not invalidate the archive.
2. This was a behavior for JDK 8 b132 (final JDK-8 release). Also, was a behavior in JDK 9 until promoted build 29.
======= Important question:
1. Was this change intentional? Perhaps to accomodate a new JigSaw model?
If yes, this should be confirmed, need to understand why this was done, and be documented.
If not, this is an omission and a bug. In this case we should weigh the importance of this fix for JDK 9 (or postpone to 10?)
========= Test case concept:
# Create shared archive
$JAVA_HOME/bin/java -Xshare:dump
# Use the shared archive, and append any class to bootclasspath
$JAVA_HOME/bin/java -Xbootclasspath/a:./hello.jar -Xshare:on -version
======== Why?
1. Logically, appending to boot class path does not change behavior of classes found within boot class path. It merely extends the class search space. Hence, it should not invalidate the archive.
2. This was a behavior for JDK 8 b132 (final JDK-8 release). Also, was a behavior in JDK 9 until promoted build 29.
======= Important question:
1. Was this change intentional? Perhaps to accomodate a new JigSaw model?
If yes, this should be confirmed, need to understand why this was done, and be documented.
If not, this is an omission and a bug. In this case we should weigh the importance of this fix for JDK 9 (or postpone to 10?)