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]

> On 7 Mar 2016, at 14:46, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> 
>> My intention was the #runtime fragment should only be used for MR-JARs.
> 
> Does that go far enough though?  I think there is a substantial amount of code which assumes (rightly) that you can build an exact path to a class in JAR URL and until today that'd work fine.

I would question the “rightly” part if directly parsing the characters of a URL without taking into account the encoding. I don’t know how much of this is just a short-cut or because URL being buggy has forced this approach.


>  It makes more sense to me that you'd only want to have to add the fragment if you want to tell it "hey I want Java 8's view of this path" or something - basically only change API when you're doing something that the API could not previously do, rather than changing JAR URLs for everyone.
> 

So, a class loader “covering” an MR-JAR would:

1) return resource URLs as they do today; and

2) any consumer can opt in by modifying that URL to get a versioned view (scheme or fragment, preferable the former in that case)

FWIW that is how the jar-based URL connection works today, you have to opt in. It’s only for MR-JAR contained resources from a class loader where that is not the case. We would need to carefully check other JDK areas, especially security/validation to see what the knock on effect it. This area is extremely fragile.


>> 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.
> 
> Yeah but that is isolated to JDK cases.

Not necessarily in the future, where it will be possible to fold libraries or applications into an image.

FWIW certain application servers also have different URL schemes for their class loaders.

Thanks,
Paul.

>  In my experience, very very few tools or containers normally construct URLs for system class path items.  I think that a substantially larger pool of software is likely to try accessing JARs by URL (at least going off of a highly unscientific bit of poking around on grepcode), and I don't think that this behavior should change from an API perspective.
> 
> --
> - DML