On 22/01/2019 4:48 am, Robert Marcano wrote:
:
So the question now is, why signed jars could affect the memory usage
of an application (we aren't doing JAR verification on our custom
launcher, yet), just by being on the java.class.path? IIRC the
initial application classpath JARs were never
Hi Goetz,
looks good to me and should fix the issue.
I just want to point out that I am not a Reviewer.
Best regards,
Arno
>-Original Message-
>From: core-libs-dev On Behalf Of
>Lindenmaier, Goetz
>Sent: Montag, 21. Januar 2019 11:01
>To: core-libs-dev@openjdk.java.net
>Subject:
Hi Arno,
thanks for looking at the change!
Best regards,
Goetz.
> -Original Message-
> From: Zeller, Arno
> Sent: Dienstag, 22. Januar 2019 14:48
> To: Lindenmaier, Goetz
> Cc: core-libs-dev@openjdk.java.net
> Subject: RE: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for
Hi Christoph,
thanks for your review. I'll update AIX to Aix before pushing.
Best regards,
Goetz.
> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 21. Januar 2019 11:43
> To: Lindenmaier, Goetz
> Cc: core-libs-dev@openjdk.java.net
> Subject: RE: RFR(XS): 8217438: Adapt
Hi Phillip,
Did you discover need for a deeper copy? If so, can you elaborate?
It may be that adding a new constructor would be cleaner.
I'd suggest clarifying the documentation of existing methods as opposed
to changing the spec and implementation and the possible risks
to clients.
Thanks,
On 1/22/19 12:29 PM, Naoto Sato wrote:
Hi Roger,
I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(),
which is the language invariant locale.
Alternatively, convert those String.format to string concatenation and they
are pretty simple format only one argument.
Other
Hi Remi,
Catching up on email, at least to my eye, the current version is easier
to read than the proposed refactoring in both cases.
I wouldn't expect this code to be performance critical so I'm inclined
to leave the code as-is unless a performance motivation is found.
Thanks for the
On 1/22/19 2:25 PM, Roger Riggs wrote:
Hi Mandy,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/
Looks good.
Other changes look good.
BTW,
> I have not found a reproducer for jdk 12, it only occurs on new
work for
> jdk 13.
Is this new code in
A ClassCircularityError can occur via the ClassDescriptor code that uses
String.format to
concatenate strings.
Please review a change to use string concatenation or a known locale
instead
of the default locale in calls to String.format.
The java.lang.constant APIs can be used early in the
Hi Mandy,
Updated webrev:
http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/
On 1/22/19 3:47 PM, Mandy Chung wrote:
On 1/22/19 12:29 PM, Naoto Sato wrote:
Hi Roger,
I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(),
which is the language invariant locale.
On Tue, Jan 22, 2019, 5:53 AM Alan Bateman On 22/01/2019 4:48 am, Robert Marcano wrote:
> >> :
> >>
> >> So the question now is, why signed jars could affect the memory usage
> >> of an application (we aren't doing JAR verification on our custom
> >> launcher, yet), just by being on the
Hi Roger,
Thanks. Modified as suggested:
http://cr.openjdk.java.net/~naoto/8216969/webrev.02/
Naoto
On 1/19/19 10:03 AM, Roger Riggs wrote:
Hi Naoto,
SimpleDateFormat: 2454, perhaps add javadoc about what it is doing and why.
Use only the official style fields and avoid using the 0x8000
Hi Roger,
I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), which
is the language invariant locale.
Other changes look good.
BTW,
> I have not found a reproducer for jdk 12, it only occurs on new work for
> jdk 13.
Is this new code in 13? l10n causes this type of
Looks good.
Thanks, Roger
On 1/22/19 3:31 PM, Naoto Sato wrote:
Hi Roger,
Thanks. Modified as suggested:
http://cr.openjdk.java.net/~naoto/8216969/webrev.02/
Naoto
On 1/19/19 10:03 AM, Roger Riggs wrote:
Hi Naoto,
SimpleDateFormat: 2454, perhaps add javadoc about what it is doing
and
Please review this change which back ports the problem listing of
LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to push
it to jdk12, but that plan got lost somewhere on the way).
Bug: https://bugs.openjdk.java.net/browse/JDK-8217349
Webrev:
Mandy, Igor - thanks! Change pushed to jdk12.
Cheers,
Mikael
> On Jan 22, 2019, at 4:34 PM, Igor Ignatyev wrote:
>
> looks good.
>
> -- Igor
>
>> On Jan 22, 2019, at 4:30 PM, Mandy Chung wrote:
>>
>> +1
>>
>> Mandy
>>
>> On 1/22/19 4:26 PM, Mikael Vidstedt wrote:
>>> Please review this
> On Jan 22, 2019, at 12:02 PM, Alan Bateman wrote:
>
> On 19/01/2019 12:46, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the fix for JDK-8217393 which updates the javadocs for
>> Attriibutes::equals to clarify its behavior to match its implementation
>>
>> —
>> hg diff
>> diff
Appreciate all your kind help in making it happen.
Regards
Patrick
From: Roger Riggs
Sent: Tuesday, January 22, 2019 10:56 PM
To: David Holmes ; Patrick Zhang
Cc: core-libs-dev
Subject: Re: 8215976: OpenJDK fails to build with GCC when the #include
inside zip.cpp comes from a non-sysroot
looks good.
-- Igor
> On Jan 22, 2019, at 4:30 PM, Mandy Chung wrote:
>
> +1
>
> Mandy
>
> On 1/22/19 4:26 PM, Mikael Vidstedt wrote:
>> Please review this change which back ports the problem listing of
>> LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to
>> push
+1
Mandy
On 1/22/19 4:26 PM, Mikael Vidstedt wrote:
Please review this change which back ports the problem listing of
LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to push
it to jdk12, but that plan got lost somewhere on the way).
Bug:
Hi David,
Thanks for running the tests.
Pushed.
Thanks, Roger
On 01/22/2019 01:45 AM, David Holmes wrote:
Mach 5 tier 1 - 3 tests passed on Linux/OS X/Windows x64 and Solaris
sparcv9.
David
On 22/01/2019 2:01 pm, David Holmes wrote:
Hi Patrick,
I'm putting this through our test system
I don’t think the launcher is doing this, it is the class loader, that’s
nothing new. You can turn on verbose security debug to see it in all versions.
--
https://Bernd.eckenfels.net
Von: core-libs-dev im Auftrag von
Robert Marcano
Gesendet: Mittwoch, Januar
Catching up on email...
On 1/8/2019 10:55 AM, Hans Boehm wrote:
The IEEE standard does say that for quiet NaNs, the value (or one of them)
"should" be preserved by most operations on the quiet NaN. I have not heard
of implementations violating this for anything other than the "quiet" bit.
Thus
On 19/01/2019 12:46, Lance Andersen wrote:
Hi all,
Please review the fix for JDK-8217393 which updates the javadocs for
Attriibutes::equals to clarify its behavior to match its implementation
—
hg diff
diff -r c5d6b4480c6c src/java.base/share/classes/java/util/jar/Attributes.java
---
On 18/01/2019 14:28, Peter Levart wrote:
...unless you actually want users to construct their own MapMode(s),
like you mentioned is the case with FileChannel.open() and
FileAttribute interface. But there this makes sense because the
backend (FileSystem) is also pluggable, so users can define
25 matches
Mail list logo
