Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

[Uwe Schindler]

> > > This is why I put the Ant developers in CC. The correct way would be
> > > to look at the *decoded* path (not just getPath() because this is also
> > > one of the "famous" traps in the URL class - one reason why it should
> > > be avoided in favor of URI). URL.toURI().getPath() is most safe to fix
> > > the issue in Apache Ant
> >
> > Part of the reason for this certainly is that the code has been written
> > before the URI class even existed.
> >
> > > (Stefan Bodewig: Should I open an issue in Ant?).
> >
> > Yes, please do. Thanks Uwe.
> 
> I opened: https://bz.apache.org/bugzilla/show_bug.cgi?id=59130
> 
> > > Maybe Ant developers can fix this code in later versions to handle
> > > URLs more correct.
> >
> > +1
> 
> Unfortunately this is not the only issue caused by this. After I tried to build
> Lucene with the patch applied, the next candidate for the issue broke:
> Apache Ivy. It was no longer able to load the ivy-settings.xml file from its JAR
> file.
> 
> The reason here is another one: It constructs the JAR file URL on its own (it
> looks like this), but does not add the #release fragment. And because of this,
> JarURLConnection does not find the file...:
> 
> [...] multiple parent causes [...]
> Caused by: java.io.FileNotFoundException: JAR entry
> org/apache/ivy/core/settings/ivysett/ivysettings-public.xml not found in
> C:\Users\Uwe Schindler\.ant\lib\ivy-2.3.0.jar
>         at
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.jav
> a:142)
>         at
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnec
> tion.java:150)
>         at
> org.apache.ivy.util.url.BasicURLHandler.openStream(BasicURLHandler.java:1
> 71)
>         at
> org.apache.ivy.util.url.URLHandlerDispatcher.openStream(URLHandlerDispat
> cher.java:74)
>         at
> org.apache.ivy.core.settings.XmlSettingsParser.doParse(XmlSettingsParser.j
> ava:157)
>         at
> org.apache.ivy.core.settings.XmlSettingsParser.parse(XmlSettingsParser.java
> :183)
>         at
> org.apache.ivy.core.settings.XmlSettingsParser.includeStarted(XmlSettingsP
> arser.java:435)
>         at
> org.apache.ivy.core.settings.XmlSettingsParser.startElement(XmlSettingsPar
> ser.java:211)
>         ... 35 more
> 
> So it looks like the Multi-release JAR file patch also breaks the other way
> round: Code constructing JAR URLs according to the standard no longer work.
> In my opinion, the JAR URLs should not change at all and the code should
> transparently choose the right release version. Maybe add a fragment only
> to explicitly state a specific version (so one would be able to load the Java 7
> version). But this could also be done using the META-INF/... path. The default
> handling should be that "old" and (I think they are standardized) JAR URLs
> still works as they should - not requiring the fragment!

I tried another project (a private one) and it failed in similar ways while loading XSL templates. This project produced no self-crafted jar:-URLs; instead it relied on relative URL resolving (the same applies to Apache Ivy).

A common pattern (especially in the "XML world") is to have relative links in your files, e.g. an XSLT file that includes another ones. If you place those XSL or XML files containing relative links in a JAR file, with previous Java versions everything worked as it should. You started the XML parser with the URL returned by the classloader and it was able to also resolve relative links between the files (because the jar: URL protocol correctly supports relative resolving of paths). So  xml/xsl file containing a reference to another file in same package using a filename like <include src="./otherfile.xsl"/> works perfectly with the JAR URL protocol. If the original file had a URL like "jar:file:....!/package/master.xsl" and this was passed to XML parser [e.g, like TranformerFactory#newTransformer(new StreamSource(classloader.getResource("package/master.xsl ").toString())], the XML parser would load "jar:file:....!/package/otherfile.xsl"

But because the fragment is lost during resolving relative URLs, this no longer works with Multi-Release JAR files. It looks like JARURLConnection throws FileNotFoundException without the #release fragment.

I hope this helps to see why using fragments as part of the identifier is not quite correct in the URL world. I'd use some other way to refer to specific versions. At least let the no-fragment case always load the version-based file. Only use a fragment to refer to another version.

Uwe