Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]

On Wed, 13 Apr 2022 22:20:14 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > update LastModified LGTM. - Marked as reviewed by chegar

Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v12]

On Wed, 3 Nov 2021 13:23:36 GMT, Aleksei Efimov wrote: >> This change implements a new service provider interface for host name and >> address resolution, so that java.net.InetAddress API can make use of >> resolvers other than the platform's built-in resolver. >> >> The following API classes

Re: [jdk17] RFR: 8266345: (fs) Custom DefaultFileSystemProvider security related loops

On Thu, 8 Jul 2021 18:21:31 GMT, Sean Mullan wrote: > Please review this fix to use the platform's default file system to avoid > recursive policy initialization > issues when a SecurityManager is enabled and the VM is configured to use a > custom file system provider. Marked as reviewed by

Re: RFR: 8267990: Revisit some uses of `synchronized` in the HttpClient API

On Mon, 31 May 2021 16:21:29 GMT, Daniel Fuchs wrote: > The Utils.remaining(List list) method assumes that it can and > should synchronize on the given list to prevent concurrent modification. In > 99% of the cases this assumption is wrong. There's only one such list (the > SSLFlowDelegate

RFR: 8267938: SCTP channel factory methods should check platform support

The SCTP channel factory methods, namely SctpChannel::open, SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw UnsupportedOperationException, if the SCTP protocol is not supported. Currently, underlying platform support is assumed once the appropriate libsctp.so.1

Re: RFR: 8267587: Update java.util to use enhanced switch [v5]

On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev wrote: >> Inspired by PR#4088. Most of the changes are done automatically using >> IntelliJ IDEA refactoring. Some manual adjustments are also performed, >> including indentations, moving comments, extracting common cast out of >> switch

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. >

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2]

On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 28 Apr 2021, at 11:38, Markus Gronlund mailto:markus.gronl...@oracle.com>> wrote: Hi Lim, JFR specific feedback can be posted to: hotspot-jfr-...@openjdk.java.net Thanks Markus. That is the appropriate list to send JFR feedback. Just to add, I

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2]

On Wed, 28 Apr 2021 09:06:29 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator)

On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] -

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator)

On Tue, 27 Apr 2021 18:40:24 GMT, Alan Bateman wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more >> detailed description of such changes, to avoid repetitions during the review >> process, is included as a separate comment. >> >> [1] -

Re: RFR: 8048199: Replace anonymous inner classes with lambdas, where applicable, in JNDI [v2]

On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote: >> ### Description >> This fix is part of a previous effort to both cleanup/modernise JNDI code, >> the details of which can be seen in >> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number >> JNDI methods under

Re: RFR: 8263754: HexFormat 'fromHex' methods should be static

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs wrote: > A number of HexFormat methods converting from strings to numbers do not use > delimiter, prefix, suffix, and uppercase parameters and would be more > convenient if the methods were static. > > These APIs were added early in JDK 17 and

Re: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v3]

On Mon, 15 Mar 2021 21:47:28 GMT, Сергей Цыпанов wrote: >> Hello, >> >> as of now `java.util.StringJoiner` still uses `char[]` as a storage for >> joined Strings. >> >> This applies for the cases when all joined Strings as well as delimiter, >> prefix and suffix contain only ASCII symbols.

Re: RFR: 8261880: Change nested classes in java.base to static nested classes where possible [v2]

On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов wrote: >> Non-static classes hold a link to their parent classes, which in many cases >> can be avoided. > > Сергей Цыпанов has updated the pull request incrementally with one additional > commit since the last revision: > > 8261880: Remove

Re: RFR: JDK-8261791: handleSendFailed in SctpChannelImpl.c potential leaks

On Wed, 17 Feb 2021 10:30:45 GMT, Chris Hegarty wrote: >> In another bug this question from me was answered by Alan Bateman : >> >> Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I >> started to wonder what happens to the allocated

Re: RFR: JDK-8261791: handleSendFailed in SctpChannelImpl.c potential leaks

On Tue, 16 Feb 2021 12:26:54 GMT, Matthias Baesken wrote: > In another bug this question from me was answered by Alan Bateman : > > Btw. while adjusting Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 , I > started to wonder what happens to the allocated memory in the same file in >

Integrated: 8261160: Add a deserialization JFR event

On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java > deserialization. The event captures the details of deserialization activity > from ObjectInputStream. The event details are similar to that of the serial

Re: RFR: 8261160: Add a deserialization JFR event [v4]

On Thu, 11 Feb 2021 16:02:09 GMT, Roger Riggs wrote: >> Chris Hegarty has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Filter **C**onfigured > > Marked as reviewed by rriggs (Reviewer). Speaking to Erik

Re: RFR: 8261160: Add a deserialization JFR event [v5]

is installed or not. The event > also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Split exception into type and message - Changes: - all: https://git.openjdk.java.net/jdk/

Re: RFR: 8261160: Add a deserialization JFR event [v3]

On Thu, 11 Feb 2021 15:45:33 GMT, Daniel Fuchs wrote: >> Chris Hegarty has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix failing test > > src/jdk.jfr/share/classes/jdk/jfr/events/DeserializationEvent.

Re: RFR: 8261160: Add a deserialization JFR event [v4]

is installed or not. The event > also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Filter **C**onfigured - Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files

Re: RFR: 8261160: Add a deserialization JFR event [v3]

is installed or not. The event > also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Fix failing test - Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files

Re: RFR: 8261160: Add a deserialization JFR event [v2]

On Thu, 11 Feb 2021 14:27:19 GMT, Roger Riggs wrote: >> Marked as reviewed by rriggs (Reviewer). > > As proposed, events are only created if there is a serialFilter in effect > (and enabled by JFR configuration). > Being able to create the events without a serialFilter in effect would be >

Re: RFR: 8261160: Add a deserialization JFR event [v2]

is installed or not. The event > also captures the filter status, if there is one. Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision: Review comments - Changes: - all: https://git.openjdk.java.net/jdk/pull/2479/files

Re: RFR: 8261160: Add a deserialization JFR event

On Tue, 9 Feb 2021 12:35:27 GMT, Chris Hegarty wrote: > This issue adds a new event to improve diagnostic information of Java > deserialization. The event captures the details of deserialization activity > from ObjectInputStream. The event details are similar to that of the serial

RFR: 8261160: Add a deserialization JFR event

This issue adds a new event to improve diagnostic information of Java deserialization. The event captures the details of deserialization activity from ObjectInputStream. The event details are similar to that of the serial filter, but is agnostic of whether a filter is installed or not. The

Re: RFR: JDK-8257401: Use switch expressions in jdk.internal.net.http and java.net.http [v4]

On Wed, 2 Dec 2020 09:42:09 GMT, Kartik Ohri wrote: >> Hi! >> Kindly review this patch to replace switch statements with switch >> expressions (where it makes sense) in the http client modules. The rationale >> is to improve readability of the code. >> Regards, >> Kartik > > Kartik Ohri has

Re: RFR: 8229867: Re-examine synchronization usages in http and https protocol handlers [v3]

On Mon, 12 Oct 2020 13:50:30 GMT, Daniel Fuchs wrote: >> Hi, >> >> This is a fix that upgrades the old HTTP and HTTPS legacy stack to use >> virtual-thread friendly locking instead of >> synchronized monitors. >> Most of the changes are mechanical - but there are still a numbers of subtle >>

Re: RFR: 8229867: Re-examine synchronization usages in http and https protocol handlers

On Thu, 8 Oct 2020 11:22:09 GMT, Daniel Fuchs wrote: > Hi, > > This is a fix that upgrades the old HTTP and HTTPS legacy stack to use > virtual-thread friendly locking instead of > synchronized monitors. > Most of the changes are mechanical - but there are still a numbers of subtle >

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

> On 8 Apr 2020, at 10:13, Rahul wrote: > > Updated patch after considering the impact of returning default parameters on > the http client. > TLS versions earlier limited to 1.2 and above by client, now will support all > versions(wrt the scenarios for this bug). > >Issue:

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

Thank you for these clarifications. We will now consider how these affect, if at all, the HTTP Client. -Chris. > On 27 Mar 2020, at 17:47, Xuelei Fan wrote: > > On 3/27/2020 10:36 AM, Chris Hegarty wrote: >> Thank you Xuelei, this very helpful. >> Sorry, but I am going t

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

Thank you Xuelei, this very helpful. Sorry, but I am going to ask just a few more clarifying questions to make sure that we’re on the same page. > On 27 Mar 2020, at 16:23, Xuelei Fan wrote: > > On 3/27/2020 5:52 AM, Chris Hegarty wrote: >> Xuelei, >> Befo

Re: RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

Xuelei, Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property. Is there a specification or other documentation describing `jdk.tls.client.protocols` ? It is

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

> On 13 Jan 2020, at 17:19, Seán Coffey wrote: > > Thanks for the reviews. All callers of EventHelper log methods are ensuring > that isLoggingSecurity() is true before proceeding. I've added an assert null > check in the 4 logger methods to ensure expectations are in place. > >

Re: RFR: 8234466: Class loading deadlock involving X509Factory#commitEvent()

> On 13 Jan 2020, at 13:14, Daniel Fuchs wrote: > > On 13/01/2020 10:28, Seán Coffey wrote: >> some off line comments suggested that I could move the jar initialization >> checks to the EventHelper class. With that in place, the EventHelper utility >> class should never initialize the

Re: Reading from a closed socket: different behavior between Linux and other operating systems

I agree with David, this is an expected difference between the socket layers on different operating systems. The different behaviours are acceptable implementations on said operating systems. Unfortunately, this results in different behaviour of the Java socket (and TCP socket channel) APIs, when

Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

The changes to the SCTP code seem ok. -Chris. > On 17 Dec 2019, at 03:00, Patrick Zhang OS > wrote: > > Thanks Martin. > > Hi net-dev, and/or security-dev Reviewers, > > Please help review and sponsor this patch if acceptable. > It does not tend to bring any functionality changes, instead

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

On 09/10/2019 14:54, Sean Mullan wrote: ... X509CertImpl extends X509Certificate which extends Certificate. Certificate has a writeReplace method. Another possible follow-on is to add readObject methods, that unconditionally throw, to both X509Certificate and X509CertImpl, since

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

Ivan, > On 4 Oct 2019, at 03:00, Ivan Gerasimov wrote: > > ... > > I've adopted your suggested changes and the test: > http://cr.openjdk.java.net/~igerasim/8230407/02/webrev/ > LGTM. > CSR was also updated accordingly: >

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

Ivan, > On 3 Oct 2019, at 04:41, Ivan Gerasimov wrote: > > ... > > So, I filed CSR: https://bugs.openjdk.java.net/browse/JDK-8231805 to cover > the addition of @throws paragraph in the javadoc of SocketPermission. > > I would really appreciate it, if someone helped to review it. > Since

Re: RFR (S) 8230407 : SocketPermission and FilePermission action list allows leading comma

Ivan, On 01/10/2019 21:26, Ivan Gerasimov wrote: Hello! The constructors of SocketPermission and FilePermission expect a String argument with comma-separated list of actions. If the list is malformed, then the constructors throw IllegalArgumentException. It turns out that the current

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

On 26/09/2019 21:10, Joe Darcy wrote: .. Yes; applying SuppressWarnings("serial") to the class will silence this new warning for all the fields. Will is also suppress other warnings, like on the serialization-related magic methods? Which would be unfortunate. -Chris.

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

> On 19 Sep 2019, at 18:32, Joe Darcy wrote: > > Hello, > > Ahead of augmenting javac's serial lint checks under JDK-8160675, it would be > helpful to mark fields in security libs classes where the class is > serializable, but a non-transient instance field does *not* have a > serialiable

Re: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed

Daniel, > On 23 May 2019, at 11:30, Daniel Fuchs wrote: > > Hi, > > I have observed an intermittent failure on Solaris. > So I changed the patch to problem-list the test on all platform. > > Is that still OK? > > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 >

Re: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed

Daniel, > On 23 May 2019, at 10:32, Daniel Fuchs wrote: > > Hi, > > Please find a patch below that temporarily problem lists > java/security/SecureClassLoader/DefineClass.java > on linux and windows until JDK-8224635 [1] is fixed: > > 8224656: Problem list

Re: [ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1

Arthur, > On 21 May 2019, at 00:50, Arthur Eubanks > wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8224256 > webrev: > http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html >

Re: [ipv6] RFR: 8224256: test/jdk/java/security/SecureClassLoader/DefineClass.java hardcodes 127.0.0.1

Arthur, > On 21 May 2019, at 00:50, Arthur Eubanks > wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8224256 > webrev: > http://cr.openjdk.java.net/~aeubanks/8224256/webrev.00/index.html >

Re: [ipv6]: 8224081: SOCKS v4 doesn't work with IPv6

Arthur, > On 17 May 2019, at 17:50, Arthur Eubanks wrote: > > Looks good. > > Trivially, maybe amend the comment to be more explicit > >86 // SOCKS V4 ( requires IPv4 ) > > -Chris. > Done > http://cr.openjdk.java.net/~aeubanks/8224081/webrev.02/ >

RFR 8220598: Malformed copyright year range in a few files in java.base

Trivially, there should be a comma after the year. Just add it. $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java ---

Re: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl

> On 26 Feb 2019, at 03:53, Xuelei Fan wrote: > > > > It makes sense to me to leave the AbstractDelegateHttpsURLConnection methods > as public. We may need to re-org the code later, but it is out of the scope > of this update. > > Here is the new webrev (only

Re: Code Review Request, JDK-8214418 HttpClient falls in running with 100% cpu usage after an error signalled on channel

Xuelei, Is it possible to update the synopsis of this bug to better reflect the underlying issue ( rather than one particular symptom )? Also, it is possible to construct a small, non-HTTP related, targeted test that verifies the fix? -Chris. On 08/01/2019 23:00, Xue-Lei Fan wrote: ping ...

Re: RFR: 8213952: Relax DNSName restriction as per RFC 1123

On Dec 4, 2018, at 1:11 AM, Seán Coffey wrote: whoops: latest webrev : http://cr.openjdk.java.net/~coffeys/webrev.8213952.v4/webrev/ Regards, Sean. Looks good. -Chris.

Re: JDK 12 RFR of JDK-8213911: Use example.com in java.net and other examples

Looks ok to me. -Chris. On 26/11/2018 21:38, joe darcy wrote: Hello, Please review a simple doc-only change to address:     JDK-8213911: Use example.com in java.net and other examples     http://cr.openjdk.java.net/~darcy/8213911.0/ Patch below. Thanks, -Joe ---

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

> On 5 Nov 2018, at 18:52, Xuelei Fan wrote: > > Hi Chris and Sean, > > There are a few feedback for the CSR approval. I updated to use > Optional for the returned value. For more details, please refer > to: > https://bugs.openjdk.java.net/browse/JDK-8213161 >

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

On 05/11/18 15:59, Alan Bateman wrote: On 05/11/2018 13:05, Langer, Christoph wrote: ... I think you'll need to do a write-up of the overall proposal so that folks can jump in and point out the implications. It's not easy to do this in a code review of a small piece of the solution.

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

On 05/11/18 12:54, Langer, Christoph wrote: Hi Chris, yes, there's no impact on Java SE with this item. No API is changed. I've set the scope to JDK, as it affects the features that are available with the "jar" filesystem provider from module jdk.zipfs. ... The reason I asked about the

Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

Hi Christoph, On 05/11/18 07:32, Langer, Christoph wrote: .. CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 Can you please add a `Scope` value to the CSR? I can't quite tell, but I assume it should be `JDK` or `Implementation`, right? I want to clarify that there is no impact on Java

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

Thanks for the updates Xuelei, some minor comments inline.. > On 1 Nov 2018, at 23:42, Xuelei Fan wrote: > > On 11/1/2018 11:24 AM, Sean Mullan wrote: >> On 10/31/18 11:52 AM, Chris Hegarty wrote: >>> Xuelei, >>> >>> On 30/10/18 20:55, Xuelei Fan

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

> On 31 Oct 2018, at 20:03, Xuelei Fan wrote: >> ... > Yes. I had the same concern about the optional operation. However, I came > to a different conclusion if I'm from viewpoint of these users that need to > use this new operation. > > If an application have to use this new operation, for

Re: A new proposal to add methods to HttpsURLConnection to access SSLSession

Xuelei, On 30/10/18 20:55, Xuelei Fan wrote: Hi, For the current HttpsURLConnection, there is not much security parameters exposed in the public APIs.  An application may need richer information for the underlying TLS connections, for example the negotiated TLS protocol version. Please

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

On 15/10/18 11:07, sha.ji...@oracle.com wrote: Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8211978/webrev.01/ AbstractSSLTubeTest.java and FlowTest.java now use the same internal.net.http.SimpleSSLContext.java This looks good to me. Thanks John. Trivially, can you

Re: RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

On 15/10/18 10:53, Weijun Wang wrote: This is bad. In the absence of better test library, module-patching, and jtreg support, this is what we end up with. It's not too bad. Maybe we can duplicate the ASCII-fied data. I don't have a strong opinion now. Duplicating the testkeys, regardless

Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives

ngths a bit more consistent with the existing >> code (the patch added excessively long lines for example). >> > > Sure I'll look into it ! -Chris. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054501.html > Best regards, Matthias > > >>

Re: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS

t look like we have to do anything special for this case, but as >> part of this fix, we should check/test that an inoperative factory is >> returned if a DTLS context is the default. >> --Sean >>> >>> Tony >>> >>> On 08/08/2018 08:52 AM, Chris Hegarty wro

Re: CSR Review: 8208641: SSLSocket should throw an exception when configuring DTLS

+1 to everything Sean said, and just to add ... This change will prevent an SSLContext from giving out socket factories when it has been configured with DTLS. What about SSL[Server]SocketFactory::getDefault when the default SSL context is DTLS? I don’t see that getDefault can throw an UOE, should

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Thanks for the review Sean, > On 23 Jul 2018, at 16:58, Sean Mullan wrote: > ... >> http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ > > A few nits and wording suggestions in the java.security file: > > "By default, several exception messages do not include potentially sensitive >

Re: Bug in HttpClient

The following issue has been filed in JIRA to track the problem with an HTTP/1.0 response without a Content-Length header: https://bugs.openjdk.java.net/browse/JDK-8207966 -Chris. > On 20 Jul 2018, at 08:38, Severin Gehwolf wrote: > > Adding net-dev > > On Fri, 2018-07-20 at 08:52

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Sean, > On 20 Jul 2018, at 18:07, Sean Mullan wrote: > > On 7/20/18 11:08 AM, Chris Hegarty wrote: >> This is ambiguous, and needs to be clarified. Surely, it is >> better to use the same wording as the serial filter: >> "Whitespace is significant and

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

> On 20 Jul 2018, at 16:15, Roger Riggs wrote: > > Hi Chris, > > The updated text is fine. > Thanks for your consideration. Updated webrev as discussed. http://cr.openjdk.java.net/~chegar/8207846/webrev.01/ -Chris.

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Roger, > On 20 Jul 2018, at 15:36, Roger Riggs wrote: > > Hi Chris, > > It is important to be clear about how whitespace is treated and within the > java.security file > there are other uses that explicitly define how whitespace is used. Right, and the usages are already inconsistent.

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Roger, > On 20 Jul 2018, at 14:52, Roger Riggs wrote: > > Hi Chris, > > It is very unusual for the processing of system properties to do *any* > parsing except for delimiters > including removing spaces, etc. It complicates the handling and sets a bad > precedent > that makes it more

RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

JDK-8204233 added a new security property, `jdk.net.includeInExceptions`, to include additional, potentially security sensitive, information in exception detail messages in the networking area. The property accepts a comma separated list of values that specifies the particular type of extra detail

RFR [11] 8205671: Remove HTTP Client tests erroneously problem listed by the TLS 1.3 integration

Seems that the integration of TLS 1.3 erroneously added a number of HTTP Client tests to the ProblemList. Previous to the TLS 1.3 push, work was done to ensure that the HTTP Client tests ran successfully with the changes in the TLS 1.3 branch. These tests should not have been problem listed.

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Xuelei, Without diving deeper into this issue, Rob’s suggested approach seems reasonable to me, and better than existing out-of-the-box behaviour. I’m not sure what issues you are thinking of, with using the read timeout in combination with a retry mechanism, in this manner? If the network is

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

On 02/06/17 00:14, Ioi Lam wrote: ... The gem is hidden in the compile.0.jta file. It contains something like: -sourcepath :/jdk/foobar/test/lib: So if my test refers to a class under /test/lib, such as jdk.test.lib.process.ProcessTools, javac will be able to locate it under

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

> On 1 Jun 2017, at 04:27, Felix Yang wrote: > > Hi Chris and Daniel, > >new webrev with a few of explicit builds than wildcard. > > http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.01/ This seems very odd to me:

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

Igor, > On 1 Jun 2017, at 04:32, Igor Ignatyev wrote: > > Hi Felix, > > I have suggested the exact opposite change[1-3] to fix the same problem. I’m sorry, but this is all just too confusing. After your change, who, or what, is responsible for building/compiling the

Re: RFR 8181299/10, Several jdk tests fail with java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper

> On 31 May 2017, at 10:42, Felix Yang wrote: > > Hi there, > >please review the patch to various jdk tests to explicitly compiling test > libraries and the lib's dependencies. Though it could be a jtreg issue (I > think so), it is necessary to get the tests

Re: RFR 8177784 Use CounterMode intrinsic for AES/GCM

On 06/04/17 21:39, Anthony Scarpino wrote: I'd like to get a review for this performance change to use the existing CounterMode parallelized intrinsic instead of GCTR's own version. The two classes were nearly identical except for the doFinal() method which doesn't belong in CounterMode.java.

Re: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy

> On 2 Jan 2017, at 11:45, Claes Redestad wrote: > > On 12/31/2016 12:45 AM, David Holmes wrote: >> I'll let you think about it so more. I'll be back in the office on Tuesday :) > > After giving it some thought I think it's better to just document the need > for some

Re: RFR 8171340: HttpNegotiateServer/java test should not use system proxy on Mac

On 16/12/16 03:43, Wang Weijun wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8171340/webrev.00/ All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)". Thank you Max. Reviewed. -Chris.

Re: [9] RFR: 8166530: sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails intermittently

> On 7 Oct 2016, at 21:33, Artem Smotrakov wrote: > > Hello, > > Please review the patch below for > sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test. > > The test has been observed to fail intermittently, but the failure is not > reproducible

Re: RFR[9]: JDK-8165566: sun/security/ssl/SocketCreation/SocketCreation.java fails intermittently: Address already in use

On 19/09/16 09:10, John Jiang wrote: Hi, Please review this fix for JDK-8165566 on test sun/security/ssl/SocketCreation/SocketCreation.java. This test takes multiple servers to use one port in sequence, but the port may not be released by previous server. This patch takes every server to be

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

On 15 Sep 2016, at 02:55, Xuelei Fan wrote: > > On 9/15/2016 9:45 AM, Artem Smotrakov wrote: >> Well, in this particular case it's not clear that it has the same issue >> with free port (at least to me). The exception occurred on client side, >> so it's not the case where

Re: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in jdk_security3 group

> On 17 Aug 2016, at 19:52, Rajan Halade <rajan.hal...@oracle.com> wrote: > > On 8/17/16 11:36 AM, Chris Hegarty wrote: > >> On 17 Aug 2016, at 18:54, Rajan Halade <rajan.hal...@oracle.com> wrote: >>> sun/net/www/protocol/https tests are redundant in jdk_s

Re: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in jdk_security3 group

> On 17 Aug 2016, at 19:52, Rajan Halade <rajan.hal...@oracle.com> wrote: > > On 8/17/16 11:36 AM, Chris Hegarty wrote: > >> On 17 Aug 2016, at 18:54, Rajan Halade <rajan.hal...@oracle.com> wrote: >>> sun/net/www/protocol/https tests are redundant in jdk_s

Re: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in jdk_security3 group

On 17 Aug 2016, at 18:54, Rajan Halade wrote: > > sun/net/www/protocol/https tests are redundant in jdk_security3 group, these > are included in jdk_net group. Yes they are, but it is very important that anyone touching TLS verify that HTTPS still works. If the jdk_net

RFR [9] 8156841: sun.security.pkcs11.SunPKCS11 poller thread retains a strong reference to the context class loader

The SunPKCS11 poller thread has no need of any user defined class loader, so should set its context class loader to null before starting, so as to not inadvertently retain a reference to the creating thread’s context class loader. In other areas that suffered from a similar issue we changed to

Re: RFR 8163489: Avoid using Utils.getFreePort() in TsacertOptionTest.java test

On 9 Aug 2016, at 16:37, Weijun Wang wrote: > > http://cr.openjdk.java.net/~weijun/8163489/webrev.00 Thanks Max, this looks good( one less use of the get free port anti-pattern! ). -Chris.

Re: RFR: 8159752: Grant de-privileged module permissions by default with java.security.policy override option

> On 14 Jul 2016, at 21:05, Sean Mullan wrote: > > Please review this change to the default Policy provider implementation to > grant de-privileged module permissions by default even when the > java.security.policy override option is specified or when the >

Re: [9] RFR: 8134267: javax/net/ssl/TLS/TestJSSE.java fails intermittently with BindException: Address already in use

On 18 May 2016, at 22:57, Artem Smotrakov wrote: > Hello, > > Please review the following patch for javax/net/ssl/TLS/TestJSSE.java test. > > The test fails intermittently with BindException because it can use a busy > port. The test uses

Re: RFR(XXS): 8155036: Remove sun.security.action.GetBooleanSecurityPropertyAction

On 25 Apr 2016, at 17:47, Claes Redestad wrote: > Hi, > > since JEP-260 encapsulates internal APIs, we could remove unused classes like > this one > > hg rm > ./src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java That should be

Re: RFR: 8154231: Simplify access to System properties from JDK code

On 20 Apr 2016, at 20:34, Claes Redestad <claes.redes...@oracle.com> wrote: > > > On 2016-04-20 20:51, Chris Hegarty wrote: >> On 20 Apr 2016, at 15:44, Claes Redestad <claes.redes...@oracle.com> wrote: >> >>> Hello, >>> >>> now

Re: RFR: 8154231: Simplify access to System properties from JDK code

On 20 Apr 2016, at 15:44, Claes Redestad wrote: > Hello, > > now that the sun.security.action package is encapsulated we can simplify > internal code to get System properties. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154231 > Webrev:

Re: RFR 8153371: Remove sun.misc.ManagedLocalsThread from jdk.crypto.pkcs11

The changes in the webrev, along with the change to the module info, look good to me. -Chris. > On 16 Apr 2016, at 01:22, Xuelei Fan wrote: > > Resend. > > Looks like there jdk.crypto.pkcs11 has no dependence on jdk.unsupported > any more. Do you want to update the

Re: RFR [9] 7067728: Remove stopThread default java.policy

On 14 Jan 2016, at 17:29, Mandy Chung <mandy.ch...@oracle.com> wrote: > >> On Jan 14, 2016, at 9:19 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >>> There are existing tests whose grants this "stopThread” RuntimePermission >>> tha

Re: RFR [9] 7067728: Remove stopThread default java.policy

ugh, there were several implementation bugs that needed to be resolved before being able to remove default grant. -Chris. > David > > On 14/01/2016 8:05 PM, Chris Hegarty wrote: >> The "stopThread” RuntimePermission is granted by default. The Thread.stop >> methods ha

Re: RFR [9] 7067728: Remove stopThread default java.policy

On 14 Jan 2016, at 16:52, Mandy Chung <mandy.ch...@oracle.com> wrote: >> On Jan 14, 2016, at 2:05 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> The "stopThread” RuntimePermission is granted by default. The Thread.stop >> methods have been de

  1   2   3   4   5   >