jdk.java.net/jdk9/jdk9/jdk/rev/42268eb6e04e
[4]
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java
-Jaikiran
# HG changeset patch
# User Jaikiran Pai <jaikiran@gmail.com>
# Date 1511499148 -19800
# Fri
Anyone willing to sponsor/review the patch please?
-Jaikiran
On 24/11/17 10:52 AM, Jaikiran Pai wrote:
As noted in [1], there's a regression in Java 9, where SSL session
resumption no longer works for SSL protocols other than TLSv1.2. The
code which is responsible for session resumption
On 10/11/17 9:41 PM, Xuelei Fan wrote:
On 11/9/2017 9:00 PM, Jaikiran Pai wrote:
2. The "How to contribute" guide states "Your patch must be
built and tested on all relevant platforms before submission." I use
Mac OS for development and that's the only system I have
> Java 1.8.0_131
> Both servers on same machine, using same Java
> Source server is using async-http-client 1.9.18
> Destination server is using Jetty 9.4.7.v20170914
> New I/O worker #10, WRITE: TLSv1.2 Handshake, length = 161
> [write] MD5 and SHA1 hashes: len = 140
> : 01 03 03 00
Thank you Xuelei, will do.
-Jaikiran
On 11/11/17 11:09 AM, Xuelei Fan wrote:
On 11/10/2017 7:38 PM, Jaikiran Pai wrote:
On 10/11/17 9:41 PM, Xuelei Fan wrote:
On 11/9/2017 9:00 PM, Jaikiran Pai wrote:
2. The "How to contribute" guide states "Your patch must be
b
(Moved from jdk9-dev list[1] to here)
I would like to contribute a patch, containing a potential fix and a
test case, to the issue reported at
https://bugs.openjdk.java.net/browse/JDK-8190917. This is going to be my
first contribution to OpenJDK, so I would need some guidance/help in
having
Last attempt - if there's no interest in this patch I'll stop pestering.
-Jaikiran
On 30/11/17 7:34 AM, Jaikiran Pai wrote:
Anyone willing to sponsor/review the patch please?
-Jaikiran
On 24/11/17 10:52 AM, Jaikiran Pai wrote:
As noted in [1], there's a regression in Java 9, where SSL
Thank you Xuelei. Please take your time.
-Jaikiran
On Wednesday, December 6, 2017, Xuelei Fan <xuelei@oracle.com> wrote:
> Hi Jaikiran,
>
> I will sponsor this contribution. I need more time for the review and
> testing.
>
> Thanks,
> Xuelei
>
> On 11/23
/2018 9:17 PM, Jaikiran Pai wrote:
Sounds fine, thank you Xuelei. Would this later be backported to Java
9 too?
-Jaikiran
On 24/02/18 12:21 AM, Xuelei Fan wrote:
Hi Jaikiran,
Thanks a lot for the update. Your code looks fine to me.
As we are working on the re-org of the implementation[1] now, I
contribution shortly after the re-org changes.
Thanks,
Xuelei
[1]:
http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016815.html
On 2/22/2018 9:58 PM, Jaikiran Pai wrote:
Given some recent changes to the class involved in this patch, in the
jdk repo (http://hg.openjdk.java.net/jdk/jdk
).
-Jaikiran
On 06/12/17 9:35 PM, Jaikiran Pai wrote:
Thank you Xuelei. Please take your time.
-Jaikiran
On Wednesday, December 6, 2017, Xuelei Fan <xuelei@oracle.com
<mailto:xuelei@oracle.com>> wrote:
Hi Jaikiran,
I will sponsor this contribution. I ne
ch servers https://github.com/openssl/openssl/pull/4463/files
-Jaikiran
On 25/08/18 11:58 AM, Jaikiran Pai wrote:
> While testing the recently released RC of JDK11 against the Apache Ant
> project, I happened to run into an odd error. I have now been able to
> reproduce this using th
While testing the recently released RC of JDK11 against the Apache Ant
project, I happened to run into an odd error. I have now been able to
reproduce this using the following, pretty trivial code:
import java.net.URL;
import java.io.InputStream;
public class Fetch {
public static void
ve testsuites, over the next few
days, with this patched version and see how it goes.
Thank you very much for the quick response and the patch.
-Jaikiran
On 25/08/18 8:18 PM, Xuelei Fan wrote:
> Hi Jaikiran,
>
> Thank you very much for the help!
>
> JDK 12 repo (JDK repo):
> http:/
lo handshake message. Please let
> me know if it works or not.
>
> If there are any other JDK 11 TLS problems with Apache Ant project,
> I'd like to know as well.
>
> Thanks,
> Xuelei
>
> On 8/25/2018 7:04 AM, Jaikiran Pai wrote:
>> Hi Xuelei,
>>
>&
://bugs.openjdk.java.net/browse/JDK-8209965
Thank you.
-Jaikiran
>
> Thanks,
> Xuelei
>
> On 8/25/2018 5:03 AM, Jaikiran Pai wrote:
>> As noted in that exception message, it appears that the server is
>> sending a "supported_groups" extension in its ServerHello
original
mail, against this patched JDK 11 version and that too passed.
-Jaikiran
On 25/08/18 9:58 PM, Jaikiran Pai wrote:
> Hi Xuelei,
>
> I had the JDK 12 repo checked out already with the latest code as of today:
>
> hg sum
> parent: 51538:a716460217ed
> 8209911: More
I noticed a typo in one of the SSL log messages, while looking into a
log file generated during a SSL handshake. Here's a trivial patch which
fixes the typo. I'm not a committer so will need help from someone to
sponsor this patch.
-Jaikiran
# HG changeset patch
# User Jaikiran Pai
# Date
Thank you Sean.
-Jaikiran
On 22/10/18 3:01 PM, Seán Coffey wrote:
> Looks fine. I'll push this for you.
>
> Regards,
> Sean.
>
> On 22/10/18 06:46, Jaikiran Pai wrote:
>> I noticed a typo in one of the SSL log messages, while looking into a
>> log file generated
Just checking - does this look like a genuine issue? Anything else I can
provide to help reproduce this?
-Jaikiran
On 18/09/18 7:06 PM, Jaikiran Pai wrote:
> I have been testing some projects that I know of, with Java 11 RC.
> There's one specific test that has been failing for me, for a
> Does it happen if using JDK crypto provider?
>
> Thanks,
> Xuelei
>
> On 9/20/2018 6:16 AM, Jaikiran Pai wrote:
>> Just checking - does this look like a genuine issue? Anything else I can
>> provide to help reproduce this?
>>
>> -Jaikiran
>>
>>
hanks,
> Xuelei
>
> On 9/20/2018 8:22 AM, Jaikiran Pai wrote:
>> Hello Xuelei,
>>
>> It doesn't happen if both the server side and client side use the JDK
>> crypto provider. However if any one side uses a different crypto
>> provider (bouncycastle in this case
FWIW - I don't think this is related to WildFly server. So I decided to
try and reproduce this in a trivial standalone program and I was able to
reproduce this. Here's the code to reproduce this issue:
import java.sql.*;
public class ConnectionCloseTest {
public static void main(final
Please consider the code that's at the end of this mail. It is a simple
client/server code where a HTTPS server is created and set to
"needClientAuth". The client then uses HttpsURLConnection and (in this
case intentionally) doesn't present any certificate, expecting the
handshake to fail. In
ed56b07
>
> Thanks,
> Xuelei
>
> On 9/14/2018 7:58 PM, Jaikiran Pai wrote:
>> I was looking at some key management code and noticed this typo in
>> X509ExtendedKeyManager. Attached is a trivial patch which fixes it. I'm
>> not a committer but have a signed OCA, so I'll need help from a sponsor.
>>
>> -Jaikiran
>>
I was looking at some key management code and noticed this typo in
X509ExtendedKeyManager. Attached is a trivial patch which fixes it. I'm
not a committer but have a signed OCA, so I'll need help from a sponsor.
-Jaikiran
# HG changeset patch
# User Jaikiran Pai
# Date 1536980065 -19800
, they will now have to expect a different exception
depending on what version of Java runtime it's running against.
-Jaikiran
On 12/09/18 9:11 PM, Jaikiran Pai wrote:
> Please consider the code that's at the end of this mail. It is a simple
> client/server code where a HTTPS server is c
; Thanks,
> Xuelei
>
> On 9/17/2018 6:30 PM, Jaikiran Pai wrote:
>> Just checking back on this one. Is this an expected change? Personally,
>> it's not a big issue in the code where this is happening for me. I'll
>> probably just change the catch block to a more generic
On 18/09/18 7:06 PM, Jaikiran Pai wrote:
> FWIW, I don't believe the signature algorithm matters
That may not be accurate since I haven't tried it out with any other
algorithm, so please ignore this bit from the original mail.
-Jaikiran
I have been testing some projects that I know of, with Java 11 RC.
There's one specific test that has been failing for me, for a while now,
during SSL handshake. Took me a while to narrow it down given the size
of the application and the nature of the exception. The exception occurs
during SSL
an,
>>
>> Thanks for the patch! It looks good to me, and I will sponsor for
>> commit.
>>
>> Thanks,
>> Xuelei
>>
>> On 1/25/2019 5:53 AM, Jaikiran Pai wrote:
>>> Attached is a trivial patch which fixes a typo in the javadoc of
>>> SSLSocket. Could one of you please review and sponsor this patch?
>>>
>>> -Jaikiran
>>>
> Severin
>
> On Tue, 2019-01-22 at 18:14 +0530, Jaikiran Pai wrote:
>> FWIW - I don't think this is related to WildFly server. So I decided
>> to try and reproduce this in a trivial standalone program and I was
>> able to reproduce this. Here's the code to reproduce
Attached is a trivial patch which fixes a typo in the javadoc of
SSLSocket. Could one of you please review and sponsor this patch?
-Jaikiran
# HG changeset patch
# User Jaikiran Pai
# Date 1548424232 -19800
# Fri Jan 25 19:20:32 2019 +0530
# Node ID fe149a371a1a961b53070e721a040c26d2e699c8
I can confirm that the sample program that I included in this mail
thread, in my first post, now works fine with BouncyCastle starting with
version 1.61 of that library. So it looks like this issue got fixed in
that version.
-Jaikiran
On 17/06/19 6:10 PM, torsten.liermann wrote:
> The current
se notes, but I think adding this detail
might help quickly diagnose this change in behaviour.
-Jaikiran
>
> Tony
>
>
> On 6/30/19 10:38 PM, Jaikiran Pai wrote:
>> It looks like there has been a change in behaviour in some of the APIs
>> exposed by javax.net.ssl.
On 02/07/19 7:35 AM, Jaikiran Pai wrote:
> Thank you Xuelei. Here's the updated webrev
> http://cr.openjdk.java.net/~jpai/webrev/8226976/01/webrev/.
- * Copyright (c) 2001, 2017, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2001, 2017, 2019 Oracle and/or its affi
Done. Here's the updated webrev
http://cr.openjdk.java.net/~jpai/webrev/8226976/02/webrev/
-Jaikiran
On 02/07/19 11:03 AM, Xuelei Fan wrote:
> The copyright date format is similar to “.. 2001, 2019, ..”.
>
> Xuelei
>
> On Jul 1, 2019, at 10:22 PM, Jaikiran Pai <mailto:jai.fo
nd update the copyright date to 2019? Otherwise, looks
> good to me.
>
> Thanks,
> Xuelei
>
> On 6/29/2019 6:03 AM, Jaikiran Pai wrote:
>> While investigating a potential regression in JDK 13+, I happened to use
>> the test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTe
Hi Xuelei, Bernd,
On 01/07/19 11:31 PM, Xuelei Fan wrote:
> On 7/1/2019 10:51 AM, Bernd Eckenfels wrote:
>> Also the `is*` prefix would point to a boolean, that’s maybe a
>> cleaner data type than a case sensitive string?
>>
> I agreed. The "isTimedout" is also used to for strings other than
>
While investigating a potential regression in JDK 13+, I happened to use
the test/jdk/javax/net/ssl/SSLSession/SessionTimeOutTests.java. This
test incorrectly uses the == operator for one of the String checks. I
have filed a bug[1] with the details and have a patch with the fix here[2].
Can I
Hi Simone,
I remember hitting a similar issue back when I was testing a EA version
of JDK 13. There was bug for it here
https://bugs.openjdk.java.net/browse/JDK-8226649 and that one says it's
fixed in "13" but doesn't have a build number associated with it. Which
build of JDK 13 are you on?
I
Hello Tony,
I'm not a reviewer, but just checking - is this following change
intentional:
-statelessSession = Boolean.parseBoolean(st);
+if (st.compareToIgnoreCase("false") == 0) {
+statelessSession = false;
+}
The Boolean.parseBoolean, that's
Actually, looking at this current code in JDK 14 (default branch), it
uses the "compareToIgnoreCase" version. So I guess, you did this change
to match with what's already there. So please ignore my previous comment.
-Jaikiran
On 19/07/19 12:18 PM, Jaikiran Pai wrote:
>
> Hel
On Tue, 15 Sep 2020 15:33:51 GMT, Daniel Fuchs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove "final"
>
> Hi Jaikiran,
>
> This is not an are
On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai wrote:
> As for this:
>
>> As long as the input stream close() method is idem potent this should be
>> safe, and AFAICS that is the case for the two
>> input stream subclasses that can be returned by ZipFile::getInput
On Tue, 15 Sep 2020 15:29:44 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove "final"
>
> src/java.base/share/classes/java/util/jar/JarFile.java line
On Wed, 7 Oct 2020 21:40:43 GMT, Brent Christian wrote:
>> I decided to slightly change the way this large manifest file was being
>> created. I borrowed the idea from
>> `Zip64SizeTest`[1] to create the file and set its length to a large value. I
>> hope that is OK. If not, let me know, I
>>
On Wed, 7 Oct 2020 21:40:57 GMT, Brent Christian wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Second round of review comments addressed
>
> Marked as reviewed by bchristi
On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai wrote:
> Can I please get a review and a sponsor for a fix for
> https://bugs.openjdk.java.net/browse/JDK-8242882?
>
> As noted in that JBS issue, if the size of the Manifest entry in the jar
> happens to be very large (such
On Thu, 24 Sep 2020 16:36:28 GMT, Brent Christian wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address the review comments and introduce an array size check in
>> JarFile.ge
t; necessary checks to throw the expected `OutOfMemoryError`. This commit also
> includes a jtreg test case which
> reproduces the issue and verifies the fix.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
Address the review comment
On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai wrote:
> Can I please get a review and a sponsor for a fix for
> https://bugs.openjdk.java.net/browse/JDK-8242882?
>
> As noted in that JBS issue, if the size of the Manifest entry in the jar
> happens to be very large (such
Can I please get a review and a sponsor for a fix for
https://bugs.openjdk.java.net/browse/JDK-8242882?
As noted in that JBS issue, if the size of the Manifest entry in the jar
happens to be very large (such that it exceeds
the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes`
ws, before initiating any /integrate command.
-Jaikiran
On 23/09/20 10:21 pm, Brent Christian wrote:
> On Wed, 23 Sep 2020 15:12:58 GMT, Jaikiran Pai wrote:
>
>>> Can I please get a review and a sponsor for a fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8242882?
On Wed, 30 Sep 2020 18:38:40 GMT, Lance Andersen wrote:
>> I think it's fine either way.
>
> If you are going to validate the message, which I probably would not, it
> would be important to make sure it document
> if the message is changed in JarFile::getBytes, that the test needs updated.
>
t; necessary checks to throw the expected `OutOfMemoryError`. This commit also
> includes a jtreg test case which
> reproduces the issue and verifies the fix.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
Second round of
On Wed, 30 Sep 2020 17:21:14 GMT, Brent Christian wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address the review comments and introduce an array size check in
>> JarFile.ge
While testing the Apache Ant project with the latest released EA of JDK
17[1] (build 26), at least one of our internal test case has started
failing. The failure relates to the new "WARNING" message that gets
printed out to System.err when some code at runtime sets the security
manager. The
Hello Sean,
On 15/06/21 12:19 am, Sean Mullan wrote:
We already are working on improvements to the warning message to show
the class and the source of the code calling
System::setSecurityManager. See
https://bugs.openjdk.java.net/browse/JDK-8268392
I just had a look at that JBS issue and
On Thu, 17 Jun 2021 17:21:04 GMT, Weijun Wang wrote:
>> More loudly and precise warning messages when a security manager is either
>> enabled at startup or installed at runtime.
>>
>> This is new PR for the `openjdk/jdk17` repo copied from
>> https://github.com/openjdk/jdk/pull/4400. A new
On Thu, 17 Jun 2021 17:21:04 GMT, Weijun Wang wrote:
>> More loudly and precise warning messages when a security manager is either
>> enabled at startup or installed at runtime.
>>
>> This is new PR for the `openjdk/jdk17` repo copied from
>> https://github.com/openjdk/jdk/pull/4400. A new
Can I please get a review for this trivial fix in the code sample in javadoc
comment of `javax.net.ssl.SSLEngine` class?
I've run `make docs-image` locally and the generated javadoc after this change
looks fine.
-
Commit messages:
- 8255674 SSLEngine class description is missing
On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai wrote:
> Can I please get a review for this trivial fix in the code sample in javadoc
> comment of `javax.net.ssl.SSLEngine` class?
>
> I've run `make docs-image` locally and the generated javadoc after this
> change looks fine.
T
On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai wrote:
> Can I please get a review for this trivial fix in the code sample in javadoc
> comment of `javax.net.ssl.SSLEngine` class?
>
> I've run `make docs-image` locally and the generated javadoc after this
> change looks f
Hello Max,
On 30/06/21 2:42 am, Wei-Jun Wang wrote:
On Jun 29, 2021, at 3:08 AM, Jaikiran Pai wrote:
On 29/06/21 12:34 pm, Jaikiran Pai wrote:
Out of all these 4 points, I think if point number 2 can be addressed such that
it just prints only once the warning for each caller class
On 30/06/21 12:10 pm, Alan Bateman wrote:
On 30/06/2021 05:51, Jaikiran Pai wrote:
In the case we are dealing with, the class is always
"org.apache.tools.ant.types.Permissions". It will always be loaded by
one single classloader (so classloaded just once). However, multiple
(resending from the correct subscribed address)
Given the recent changes around the Java SecurityManager deprecation,
the Ant project has been asking for user feedback on how this change
impacts them with their Ant build files/tasks. So far we have received
two separate user reports around
On 29/06/21 12:21 am, Alan Bateman wrote:
On 28/06/2021 18:16, Jaikiran Pai wrote:
On a slightly related note, I was wondering why we decided to go with
what appears to be a bit more aggressive approach to these warning
messages as compared to what was done with the illegal reflective
On 29/06/21 12:34 pm, Jaikiran Pai wrote:
> Out of all these 4 points, I think if point number 2 can be
addressed such that it just prints only once the warning for each
caller class, then the issue noted by users of Ant build file will be
drastically reduced. I haven't yet tr
On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote:
>> Add a cache to record which sources have called `System::setSecurityManager`
>> and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote:
> This change modifies the default value of the `java.security.manager` system
> property from "allow" to "disallow". This means unless it's explicitly set to
> "allow", any call to `System.setSecurityManager()` would throw an UOE.
>
> The
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote:
> This change modifies the default value of the `java.security.manager` system
> property from "allow" to "disallow". This means unless it's explicitly set to
> "allow", any call to `System.setSecurityManager()` would throw an UOE.
>
> The
On Mon, 23 Aug 2021 12:09:42 GMT, Weijun Wang wrote:
> > Would this then allow the security manager to be used? In other words, can
> > the value of `java.security.manager` be changed dynamically at runtime or
> > is it restricted to be set only at launch time (via command line arugment
> >
(resending from the correct subscribed email address)
I see that System.setSecurityManager(...) will start throwing exception
by default starting Java 18[1]. I have been following the JEP 411,
mostly in context of the Apache Ant project. I think we (Ant) are in a
OK shape for Java 17 when it
On Wed, 22 Sep 2021 10:36:37 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8273894?
>
> Given the nature of the code in `ReferralsCache`, I haven't been able to add
> a
On Wed, 22 Sep 2021 10:36:37 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> noted in https://bugs.openjdk.java.net/browse/JDK-8273894?
>
> Given the nature of the code in `ReferralsCache`, I haven't been able to add
> a
The commit here tries to address an intermittent failure reported in
https://bugs.openjdk.java.net/browse/JDK-8254267.
The `LogParameters` test case sets the log level to `ALL` for the
`java.lang.String.class` and then attaches a handler to it. It then proceeds to
write out a log message at
't allow me to
> do anything. So I decided to directly create this PR instead of first
> commenting there.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
fix copyright year
-
Changes:
- all: https://git.openjdk.ja
On Wed, 13 Oct 2021 14:00:35 GMT, Weijun Wang wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix copyright year
>
> test/jdk/javax/xml/crypto/dsig/LogParameters.java line 2:
>
On Wed, 13 Oct 2021 14:22:16 GMT, Jaikiran Pai wrote:
>> The commit here tries to address an intermittent failure reported in
>> https://bugs.openjdk.java.net/browse/JDK-8254267.
>>
>> The `LogParameters` test case sets the log level to `ALL` for the
&g
't allow me to
> do anything. So I decided to directly create this PR instead of first
> commenting there.
Jaikiran Pai has updated the pull request incrementally with two additional
commits since the last revision:
- add a summary to the test as well as use a different logger than
On Wed, 13 Oct 2021 17:15:53 GMT, Daniel Fuchs wrote:
> Aside note: why `String.class.getName()`? is the logged message generated by
> java.lang.String? that would be dangerous - as strings are used all over the
> place in java.util.logging...
I had a look at the original issue for which this
On Thu, 14 Oct 2021 03:25:07 GMT, Jaikiran Pai wrote:
>> The commit here tries to address an intermittent failure reported in
>> https://bugs.openjdk.java.net/browse/JDK-8254267.
>>
>> The `LogParameters` test case sets the log level to `ALL` for the
&g
On Wed, 13 Oct 2021 10:49:57 GMT, Jaikiran Pai wrote:
> The commit here tries to address an intermittent failure reported in
> https://bugs.openjdk.java.net/browse/JDK-8254267.
>
> The `LogParameters` test case sets the log level to `ALL` for the
> `java.lang.String.class` an
Can I please get a review for this change which proposes to fix the issue noted
in https://bugs.openjdk.java.net/browse/JDK-8273894?
Given the nature of the code in `ReferralsCache`, I haven't been able to add a
new jtreg test case to reproduce the issue and verify this fix. Just to be sure
On Mon, 21 Feb 2022 08:13:01 GMT, John Jiang wrote:
> JDK-8282158 changed ECParameters' package from sun.security.util to
> java.security by accident.
>
> So sorry for this trouble!
I'm not a Reviewer, but this change looks fine in context of the accidental
change introduced in
On Mon, 21 Feb 2022 07:50:22 GMT, John Jiang wrote:
>> sun.security.util.ECParameters class supports three AlgorithmParameterSpec
>> types, exactly ECParameterSpec, ECGenParameterSpec and
>> ECKeySizeParameterSpec, however the InvalidParameterSpecException messages
>> missed
On Sun, 6 Feb 2022 19:51:05 GMT, Sean Mullan wrote:
>> This fixes a bootstrapping issue if a custom system class loader is set with
>> the `-Djava.system.class.loader` option and the custom class loader is
>> inside a signed JAR. In order to load the custom class loader, the runtime
>> must
On Tue, 1 Feb 2022 21:54:29 GMT, Sean Mullan wrote:
> This fixes a bootstrapping issue if a custom system class loader is set with
> the `-Djava.system.class.loader` option and the custom class loader is inside
> a signed JAR. In order to load the custom class loader, the runtime must
>
On Tue, 26 Apr 2022 00:27:43 GMT, Mark Powers wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8285504
>>
>> JDK-8273046 is the umbrella bug for this bug. The changes were too large for
>> a single code review, so it was decided to split into smaller chunks. This
>> is one such chunk:
>>
On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov wrote:
> Hashtable doesn't allow `null` values. So, instead of pair
> `containsKey`/`remove` calls, we can directly call `remove` and then compare
> result with `null`.
>
On Mon, 13 Jun 2022 07:26:32 GMT, Matthias Baesken wrote:
> Hi Daniel, should we maybe better print something like "check for not allowed
> characters" in the exception ? Do you have an easy and cheap way in mind to
> the get the unsupported character (in this case "_") to add it to the output
On Fri, 6 May 2022 09:14:53 GMT, Daniel Fuchs wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java
>> line 1039:
>>
>>> 1037: e.abort(selectorClosedException());
>>> 1038: } else {
>>> 1039: selector.wakeup();
>>
>>
On Fri, 6 May 2022 09:38:38 GMT, Daniel Fuchs wrote:
>> Hi, please find here a patch that solves a rare intermittent test failure
>> observed in the test `java/net/httpclient/ExecutorShutdown.java`
>>
>> A race condition coupled with some too eager synchronization was causing a
>> deadlock
On Wed, 27 Apr 2022 16:22:38 GMT, Xue-Lei Andrew Fan wrote:
>> Please review this password cleanup enhancement in the PasswordCallback
>> implementation. This is one of the effort to clean up the buffered
>> passwords.
>>
>> The PasswordCallback.setPassword() clones the password, but is not
On Wed, 27 Apr 2022 14:03:15 GMT, Daniel Jeliński wrote:
> Please review this follow up to #8349.
>
> As JCK pointed out, `permits` is supposed to throw IAE on null input.
> However, now that we're looking up the result in a `ConcurrentHashMap`, a
> `NullPointerException` is thrown. This
On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote:
> Hi, please find here a patch that solves a rare intermittent test failure
> observed in the test `java/net/httpclient/ExecutorShutdown.java`
>
> A race condition coupled with some too eager synchronization was causing a
> deadlock between
On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote:
> Hi, please find here a patch that solves a rare intermittent test failure
> observed in the test `java/net/httpclient/ExecutorShutdown.java`
>
> A race condition coupled with some too eager synchronization was causing a
> deadlock between
On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote:
> Hi, please find here a patch that solves a rare intermittent test failure
> observed in the test `java/net/httpclient/ExecutorShutdown.java`
>
> A race condition coupled with some too eager synchronization was causing a
> deadlock between
On Thu, 5 May 2022 19:03:13 GMT, Daniel Fuchs wrote:
> Hi, please find here a patch that solves a rare intermittent test failure
> observed in the test `java/net/httpclient/ExecutorShutdown.java`
>
> A race condition coupled with some too eager synchronization was causing a
> deadlock between
100 matches
Mail list logo
