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)

[David M. Lloyd]

On 03/07/2016 03:43 AM, Paul Sandoz wrote:
> 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.
> [...]
> 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.

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

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