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)

[Paul Sandoz]

Hi Andre,

> On 6 Mar 2016, at 00:15, André-John Mas  wrote:
> 
> Hi,
> 
> Given the issues we are seeing, and I suspect this is not the only code with 
> these assumptions, is there any way this functionality can be limited to 
> "multi-release aware" code, either via a constructor parameter or a new 
> method? What is the most elegant approach?
> 

For resource URLs, associated with an MR-JAR, and obtained from a class loader, 
here are three possible routes we could take:

1) Modify the resources URLs, cognisent of the known issues processing such 
URLs;
2) Resources URLs are reified; or
3) Resources URLs are not modified (meaning they are not runtime versioned).


By 2) i mean that:

  URL u = loader.getResource(“foo/Bar.class”)

may return u that is say:

  “jar:file:/….!/META-INF/versions/9/foo/Bar.class”

rather than:

  “jar:file:/….!/foo/Bar.class”

But we need to work through the implications of that approach.

Paul.





signature.asc
Description: Message signed with OpenPGP using GPGMail

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)

[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  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 

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