Hi Stefan, > -----Original Message----- > From: Stefan Bodewig [mailto:bode...@apache.org] > Sent: Saturday, March 05, 2016 7:56 PM > To: d...@ant.apache.org; Uwe Schindler <uschind...@apache.org> > Cc: 'Alan Bateman' <alan.bate...@oracle.com>; core-libs- > d...@openjdk.java.net; rory.odonn...@oracle.com; d...@ant.apache.org; > 'Steve Drach' <steve.dr...@oracle.com> > Subject: Re: 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) > > On 2016-03-05, Uwe Schindler wrote: > > > 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.java:142) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150) at org.apache.ivy.util.url.BasicURLHandler.openStream(BasicURLHandler.java:171) at org.apache.ivy.util.url.URLHandlerDispatcher.openStream(URLHandlerDispatcher.java:74) at org.apache.ivy.core.settings.XmlSettingsParser.doParse(XmlSettingsParser.java:157) at org.apache.ivy.core.settings.XmlSettingsParser.parse(XmlSettingsParser.java:183) at org.apache.ivy.core.settings.XmlSettingsParser.includeStarted(XmlSettingsParser.java:435) at org.apache.ivy.core.settings.XmlSettingsParser.startElement(XmlSettingsParser.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! Uwe
