We’ve identified two possible ways to address issue JDK-8151542. <https://bugs.openjdk.java.net/browse/JDK-8151542>
One way is to append a #runtime fragment to the input URL in URLClassPath to convey to URLJarFile that we want to have the JarFile opened with the parameter Release.RUNTIME, so any loaded classes are runtime versioned. This is currently implemented and was integrated as part of issue JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734> For this case, a resource URL returned from ClassLoader.getResource(s) is reified, that is the returned URL does not have the #runtime fragment appended to it, instead the URL points directly to the desired entry. The other way is to create a new URL scheme “mrjar” so that when URLJarFile sees the URL it knows to open the Jarfile with the Release.RUNTIME parameter. No fragment is required. A returned resource URL will be of the form “mrjar:<url>!/{entry} We’ve put together the following list of pros/cons for each approach. We’re soliciting feedback from the mailing list. We currently have a working patch for the reification approach, but not one for the new scheme approach. reification pros — . produces a standard/normal URL pointing directly to the jar entry . the String equivalent is parsable so it shouldn’t affect legacy code reification cons — . exposes the internals of a jar (i.e explicitly shows the META-INF/versions directory) . the input URL is modified by attaching a #runtime fragment to it . URL is not “portable” across jars as platform release version changes mrjar scheme pros — . one URL that always points to runtime versioned entries . the same URL (with entry appended) is returned by the getResource method . portable across different platform releases . jigsaw has also introduced a new URL scheme mrjar scheme cons — . may break String based parsing of URLS . non-standard URL scheme . what does it mean with non MR files? . we haven’t put together a prototype yet As I said, we’re soliciting feedback from the list. My personal opinion is that we should go with what we have, the reification approach, since it’s least likely to break existing code.
