Summary

Change java.net.URLCassLoader to disable support for "JAR Index". JAR Index is a legacy optimization specified in the JAR File spec to allow downloading of JAR files to be postponed when loading applets or other classes over the network.

Problem

JAR Index is a legacy feature that doesn't interact well with other features and has several long standing issues. Fixing these issues would add significant complexity that doesn't seem worth doing.

The JAR index file (META-INF/INDEX.LIST) is ignored in modular JARs. It works in some cases with Multi-Release JAR but problematic for cases where the versioned section has classes/resources in "new packages".

One long standing issue is that URLClassLoader::findResources does not locate resources in more than one JAR file when a JAR index is present. Another one is that JarInputStream::getManifest does not return the manifest because the index is stored as the first entry in the JAR file.

We had hoped to deprecate or remove it in Java 9 but didn't get to it.

Solution

Disable the "JAR Index" for the application class path and the java.net.URLClassLoader implementation, this means that the contents of INDEX.LIST file will be ignored by the application class loader and URLClassLoader objects created by user code.

Add the system "jdk.net.URLClassPath.enableJarIndex" as a temporary mechanism to re-enable the feature. If set to an empty string or the value "true" then JAR Index will be re-enabled, and work the same as JDK 1.3-17.

No change to the jar tool. The jar -i option will continue to create an index and update a JAR file with update an existing index. Projects that use JDK 18 to build a project and targets an older release will not observe any change.

A release note will be created to document the change and the system property to re-enable the feature if needed.

Specification

No changes to the API docs.

We may tweak the JAR file spec to make it clearer that support for JAR index is optional for class loaders that load applets or load classes over the network. This may be the topic for a future CSR.