Directing to jdk-updates-dev...
Paul
-Original Message-
From: core-libs-dev on behalf of Vyom
Tiwari
Date: Monday, January 10, 2022 at 10:51 PM
To: net-dev , core-libs-dev
Cc: "kusriniva...@vmware.com"
Subject: jdk11u build failure on Windows
Hi,
I am facing the build issue with
My apologies. I relied on the other reviewers. I'll do an independent review in
the future.
Thanks,
Paul
On 10/14/20, 11:02 AM, "core-libs-dev on behalf of Roger Riggs"
wrote:
On Wed, 14 Oct 2020 15:01:42 GMT, Roger Riggs wrote:
>> Due to the requirement for multiple reviewers, I
Looks good, and trivial.
Thanks,
Paul
On 4/30/20, 8:23 AM, "core-libs-dev on behalf of Volker Simonis"
wrote:
Hi,
can I please get a review for the following trivial change which fixes
the Amazon copyright in several test files:
: core-libs-dev On Behalf
> Of Hohensee, Paul
> Sent: Montag, 23. März 2020 19:29
> To: Doerr, Martin ; core-libs-
> d...@openjdk.java.net; jdk-updates-...@openjdk.java.net
> Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.se
The changeset references JDK-8223326, which is private. If possible, ask Oracle
to make it public so we can do a normal backport rather than file an
11u-specific issue. The backport itself looks fine.
Thanks,
Paul
On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin"
wrote:
Java SE 11
for this change to go into 11u.
HTH,
-Joe
On 2/19/2020 8:09 AM, Hohensee, Paul wrote:
> So, not backportable?
>
> Paul
>
> On 2/19/20, 5:23 AM, "naoto.s...@oracle.com"
wrote:
>
> Hi Joe, Paul,
>
ec change to a Java SE API so would be out of bounds
> for 11u without a maintenance update of Java SE 11.
>
> Naoto, do you agree with that analysis?
>
> Thanks,
>
> -Joe
>
> On 2/18/2020 5:44 PM, Hohensee, Paul wrote:
>>
Please review the CSR https://bugs.openjdk.java.net/browse/JDK-8239395 for a
backport of JDK-8215181 to jdk11u. It’s identical to the original CSR.
Original JBS issue: https://bugs.openjdk.java.net/browse/JDK-8215181
Original CSR: https://bugs.openjdk.java.net/browse/JDK-8218770
Backport JBS
This revision looks fine to me.
Thanks,
Paul
On 12/16/19, 7:52 PM, "core-libs-dev on behalf of Verghese, Clive"
wrote:
Hi Volker,
Thank you for the feedback.
I have update the revision to reflect your comments.
http://cr.openjdk.java.net/~phh/8235699/webrev.01/
Lgtm. I'll sponsor it and tag the JBS issue with jdk8u-fix-request.
Thanks,
Paul
On 12/9/19, 4:55 AM, "jdk-updates-dev on behalf of Severin Gehwolf"
wrote:
Hi Adam,
This looks like an RFR for OpenJDK 8u. Adding the appropriate mailing
list (jdk8u-dev not jdk-updates-dev;
This looks good to me, assuming the i18n people are ok with using "Turkey Time"
instead of some other designation.
Thanks,
Paul
On 11/25/19, 10:44 AM, "core-libs-dev on behalf of Yang, Letu"
wrote:
Fixed in https://cr.openjdk.java.net/~xliu/8234288/webrev.04/ Thanks!
From:
I agree, looks fine.
Paul
On 6/2/19, 11:46 PM, "jdk-updates-dev on behalf of Langer, Christoph"
wrote:
Hi,
please help reviewing a backport to OpenJDK 11u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8139965
11u-webrev:
Thanks, Andrew. :)
On 4/9/19, 10:27 AM, "Andrew John Hughes" wrote:
On 09/04/2019 18:18, Hohensee, Paul wrote:
> I meant the current webrev
>
> https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/
>
> is fine. Just backport what's
I meant the current webrev
https://cr.openjdk.java.net/~andrew/openjdk8/8205432/webrev.02/
is fine. Just backport what's in tip and fix whatever's wrong later as another
backport or backports.
Paul
On 4/9/19, 8:56 AM, "core-libs-dev on behalf of Hohensee, Paul"
wrot
+1.
Paul
On 4/8/19, 8:28 PM, "core-libs-dev on behalf of Andrew John Hughes"
wrote:
On 08/04/2019 09:25, Deepak Kejriwal wrote:
> Hi Andrew,
>
> Thanks for working on this. Please find below few minor comments:-
>
> 1>. For
I added the 'jdk8u-fix-request' tag to these issues.
Paul
On 2/28/19, 3:13 AM, "core-libs-dev on behalf of Deepak Kejriwal"
wrote:
Hi All,
Please approve the backport of following bugs to 8u-dev.
JDK-8202088 : Japanese new era implementation
Redirecting to core-libs-dev. I filed
https://bugs.openjdk.java.net/browse/JDK-8213045.
Paul
On 10/26/18, 10:50 AM, "jdk-dev on behalf of Hohensee, Paul"
wrote:
This would go to core-libs-dev, and would be a spec change since it adds a
class. The concept could be expanded to
I've filed https://bugs.openjdk.java.net/browse/JDK-8210985.
Thanks for looking into this.
Paul
On 9/17/18, 8:37 AM, "Sean Mullan" wrote:
On 9/12/18 2:25 PM, Hohensee, Paul wrote:
> Thanks very much for investigating. We're aware that the cache size can
be set by the u
PI as well as the
"javax.net.ssl.sessionCacheSize" system property to customize the cache
size.
--Sean
On 9/11/18 12:02 PM, Sean Mullan wrote:
> cross-posting to security-dev since this is related to SSL/TLS.
>
> On 9/11/18 11:41 AM, Hohensee, Paul wrote:
>> The d
The default value for the maximum number of entries in the SSL session cache
(which is a SoftReference cache) is infinite, and the entry timeout is 24
hours. With larger heaps, we’re running into situations where the cache ends up
with several million entries when the 24 hours are up. They’re
I’d file an RFE to refactor the Deflater.c code.
Following the zlib code is the right thing to do in order to stay consistent,
even if it’s a bit rough.
So, ship it.
On 11/22/17, 9:43 AM, "Seán Coffey" <sean.cof...@oracle.com> wrote:
On 22/11/2017 15:46, Hohe
If the fix is from the zlib project, then ignore the following, since it’s
their code.
In Deflater.c: the existing significant code duplication between the arms of
the if-else gives one pause. E.g., in the new file, compare lines 148/183 and
155/190. Might be bugs lurking at 183 and 190.
In
A double negative (!Files.notExists) somewhat unusual coding and will perplex
people reading it. They might even switch it back to Files.exists as a style
cleanup, so I recommend adding a comment explaining why you’re using it.
Thanks,
Paul
On 7/25/17, 5:08 PM, "core-libs-dev on behalf of
In short, no current plans to add java.util.Pair.
-Joe
On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
>
> At Amazon, many projects depend on JavaFX to get only a single class,
>
> -Joe
>
>
> On 7/13/2017 10:07 AM, Hohensee, Paul wrote:
>> See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
>>
>> At Amazon, many projects depend on JavaFX to get only a single class,
>> namely javafx.
See the ancient https://bugs.openjdk.java.net/browse/JDK-4947273.
At Amazon, many projects depend on JavaFX to get only a single class, namely
javafx.util.Pair. That means that we must distribute OpenJFX along with our
internal OpenJDK distribution, or split javafx.util.Pair out into a separate
26 matches
Mail list logo
