ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Sandoz <paul.san...@oracle.com>
Subject 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)
Date Mon, 07 Mar 2016 09:43:48 GMT
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 <Alan.Bateman@oracle.com> 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 <blush/>

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


Mime
View raw message