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
