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)

Hi Andre, > On 6 Mar 2016, at 00:15, André-John Mas wrote: > > Hi, > > Given the issues we are seeing, and I suspect this is not the only code with > these assumptions, is there any way this functionality can be limited to > "multi-release aware" code, either via a

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)

Hi, Given the issues we are seeing, and I suspect this is not the only code with these assumptions, is there any way this functionality can be limited to "multi-release aware" code, either via a constructor parameter or a new method? What is the most elegant approach? Andre > On 5 Mar, 2016,

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)

On 2016-03-05, Uwe Schindler wrote: > This is why I put the Ant developers in CC. The correct way would be > to look at the *decoded* path (not just getPath() because this is also > one of the "famous" traps in the URL class - one reason why it should > be avoided in favor of URI).

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)

> On 7 Mar 2016, at 14:46, David M. Lloyd 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

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)

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

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)

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

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)

On 5/03/2016 11:50 PM, Claes Redestad wrote: Hi, similar issues were discovered too late to stop b108, e.g., https://bugs.openjdk.java.net/browse/JDK-8150920. Fix is already in jdk9/dev, so I think the next build should be more well-behaved and hope we can provide it more promptly than

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)

> > > This is why I put the Ant developers in CC. The correct way would be > > > to look at the *decoded* path (not just getPath() because this is also > > > one of the "famous" traps in the URL class - one reason why it should > > > be avoided in favor of URI). URL.toURI().getPath() is most safe

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)

Hi Stefan, > -Original Message- > From: Stefan Bodewig [mailto:bode...@apache.org] > Sent: Saturday, March 05, 2016 7:56 PM > To: d...@ant.apache.org; Uwe Schindler > Cc: 'Alan Bateman' ; core-libs- > d...@openjdk.java.net;

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)

Thanks Alan, I am glad that the appending of "#resource" is indeed a bug. > > 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,

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)

Hi Claes, is there a way to just build a new runtime library without compiling a full JDK (including Hotspot). So just replacing the jimage files locally? Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany

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)

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

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)

Hi, similar issues were discovered too late to stop b108, e.g., https://bugs.openjdk.java.net/browse/JDK-8150920. Fix is already in jdk9/dev, so I think the next build should be more well-behaved and hope we can provide it more promptly than normal. If you can build OpenJDK from jdk9/dev and

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)

Hi OpenJDK Core Developers, you may know the Apache Lucene team is testing early access releases of Java 9. We reported many bugs already, but most of them only applied to Hotspot and Lucene itsself. But this problem since build 108 is now really severe, because it breaks the build system