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
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,
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).
> 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
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
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
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
> > > 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
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;
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,
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
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
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
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
14 matches
Mail list logo