Hi Uwe, Alan, Uwe, thanks so much for testing and investigating, that is very helpful and really appreciated. The EA process is working as intended, although i wish the result was not so debilitating in this case. Sorry about that.
> On 5 Mar 2016, at 15:03, Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 05/03/2016 13:24, Uwe Schindler wrote: >> : >> >> I'd suggest to please ASAP revert the Multi-Release JAR file patch and >> provide a new preview build as soon as possible. I think there is more work >> needed to fix this. If this does not revert to the original state, it will >> be impossible to build and test Lucene, Elasticsearch,.... (and almost every >> Java project out there!). So short: We cannot test anymore and it is likely >> that we cannot support Java 9 anymore because the build system used by most >> Java projects behind the scenes does not bootstrap itself anymore. >> > Sigh, I think those of us that reviewed this missed the point that the > fragment is appended by default. Yes :-( i missed that in review <blush/> Here is a possible fix: URLClassPath.java: — /** * This class is used to maintain a search path of URLs for loading classes * and resources from both JAR files and directories. @@ -760,7 +759,11 @@ try { // add #runtime fragment to tell JarURLConnection to use // runtime versioning if the underlying jar file is multi-release - url = new URL(getBaseURL(), ParseUtil.encodePath(name, false) + "#runtime"); + if (jar.isMultiRelease()) { + url = new URL(getBaseURL(), ParseUtil.encodePath(name, false) + "#runtime"); + } else { + url = new URL(getBaseURL(), ParseUtil.encodePath(name, false)); + } if (check) { URLClassPath.check(url); } With that fix i can successfully build Lucene (i think the problem with Ivy is the same underlying cause as with Ant. We have also noticed problems with Jetty). My intention was the #runtime fragment should only be used for MR-JARs. We may need to reconsider that given the fragility of processing URLs that have been reported, although MR-JARs are new and it will take time for this to work through the eco-system allowing time to weed out the bugs. Ideally the best solution is to change the URL scheme, say “mrjar:file:/…!/…class” only for MR-JARs of course, but i considered this might be even more invasive for class scanners etc, (assuming URLs are processed correctly). However, the Jigsaw image is already adjusting the scheme for classes in an image: l.getResource("java/net/URL.class”) -> jrt:/java.base/java/net/URL.class and that will also impact other stuff folded into the image. So perhaps we should revisit? Tricky tradeoffs here. > This will of course break code that parses URL strings in naive ways > (anything looking for ".xml" should be looking at the path component of > course). I'll create a bug for this now, assuming you haven't created one > already. > Alan created: https://bugs.openjdk.java.net/browse/JDK-8151339 Thanks, Paul. > One general point is that the purpose of EA builds and timely testing by > Lucene and other projects is invaluable for shaking out issues. There will be > issues periodically and much better to find these within a few days of > pushing a change rather than months later. > > -Alan
signature.asc
Description: Message signed with OpenPGP using GPGMail