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
