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)

[Paul Sandoz]

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.Bateman at 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