Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Hi Andrew, > On 15 Feb 2019, at 16:51, Andrew Dinn wrote: > > The latest round of changes to the JEP and draft implementation are now > available for review: > > JEP:http://openjdk.java.net/jeps/8207851 > webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.05/ I'm only following this is

Re: RFR: jsr166 integration 2019-02

> On 9 Feb 2019, at 19:25, Martin Buchholz wrote: > > Thanks, Chris. > > On Sat, Feb 9, 2019 at 6:34 AM Chris Hegarty <mailto:chris.hega...@oracle.com>> wrote: >> 8215359: InnocuousForkJoinWorkerThread.setContextClassLoader needlessly >> throws >> h

Re: RFR: jsr166 integration 2019-02

> On 8 Feb 2019, at 23:42, Martin Buchholz wrote: > > ... > 8195057: java/util/concurrent/CountDownLatch/Basic.java failed w/ Xcomp > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/CountDownLatch-Basic/index.html > >

Re: [12] RFR: 8216546: Support new Japanese era in java.lang.Character for Java SE 11

> On 31 Jan 2019, at 17:07, Naoto Sato wrote: > > Hi Chris, > > Thank you for the comments. I updated the CSR and the webrev: > > https://bugs.openjdk.java.net/browse/JDK-8217938 > https://cr.openjdk.java.net/~naoto/8216546/webrev.01/ Thanks Naoto. Reviewed. -Chris

Re: [12] RFR: 8217892: Clarify the support for the new Japanese era in java.time.chrono.JapaneseEra

Naoto, > On 31 Jan 2019, at 00:51, naoto.s...@oracle.com wrote: > > .. > https://bugs.openjdk.java.net/browse/JDK-8217939 > http://cr.openjdk.java.net/~naoto/8217892/webrev.00/ The changes look good. Reviewed. -Chris.

Re: [12] RFR: 8216546: Support new Japanese era in java.lang.Character for Java SE 11

Naoto, > On 31 Jan 2019, at 00:35, naoto.s...@oracle.com wrote: > > ... > > https://bugs.openjdk.java.net/browse/JDK-8217938 > http://cr.openjdk.java.net/~naoto/8216546/webrev.00/ This looks good. Just a few very minor comments. 1) To be consistent can you please include the addition of the

Re: RFR : 8217093: Support extended-length paths in parse_manifest.c on windows

On 28/01/2019 16:09, Baesken, Matthias wrote: you should think of a JLI_open function and then you can put its implementation into the Windows version of java_md.c. Hi Christoph, I like this idea . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8217093.4/ This is the one. Lo

Re: RFR: JDK11U JDK-8216546: Support new Japanese era in java.lang.Character for Java SE 11

On 25/01/2019 18:35, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216546 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8216546/"http://cr.openjdk.java.net/~rpatil/8216546/ This change looks good Deepak. Reviewed. I have added myself a

Re: RFR: JDK8U JDK-8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8

On 25/01/2019 18:37, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8216396 Webrev: http://cr.openjdk.java.net/~rpatil/8216396/ This change looks good Deepak. Reviewed. -Chris.

Re: RFR: JDK11U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra

On 26/01/2019 10:57, Deepak Kejriwal wrote: Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk11u/webrev.00/ This looks good Deepak. Reviewed. One minor comment. "The of(int) and valueOf(String) methods ...", th

Re: FW: RFR: JDK8U Backport of JDK-8212941: Support new Japanese era in java.time.chrono.JapaneseEra

On 27/01/2019 11:54, Deepak Kejriwal wrote: ... Hi All, JBS report: https://bugs.openjdk.java.net/browse/JDK-8212941 Webrev: http://cr.openjdk.java.net/~rpatil/8212941/jdk8u/webrev.00/ This looks good Deepak. Reviewed. One minor comment. "The of(int) and valueOf(String) methods ...",

Re: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates

> On 5 Jan 2019, at 17:03, Alan Bateman wrote: > > On 04/01/2019 17:18, Chris Hegarty wrote: >> Will compilations with `--release N-1` wind back the set of allowable >> identifiers? It possibly should, if so how does one do similar when/if >> the set of currency c

Re: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates

t of currency characters is expanded in an update release? -Chris. > Naoto > > On 1/4/19 6:13 AM, Chris Hegarty wrote: >> On 1/3/19 10:26 PM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix to the following issue (and its a

Re: [12] RFR: 8215303: Allowing additional currency code points from later Unicode updates

On 1/3/19 10:26 PM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue (and its approved CSR): > > https://bugs.openjdk.java.net/browse/JDK-8215303 > https://bugs.openjdk.java.net/browse/JDK-8215305 > > The proposed changeset is located at: > > http://cr.openjdk.java

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

> On 19 Dec 2018, at 15:01, Chris Hegarty wrote: > > Martin, > > Is it possible to use the the JDK’s test library jdk.test.lib.RandomFactory, > so that the initial seed is captured and rep*l*ayable. -Chris.

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

Martin, Is it possible to use the the JDK’s test library jdk.test.lib.RandomFactory, so that the initial seed is captured and repayable. Also, please add the jtreg key so that the test is identifiable as using randomness: `@key randomness` . -Chris. > On 19 Dec 2018, at 14:47, Martin Buchholz

Re: [test] 8214445 : java/net/URL/HandlerLoop has illegal reflective access

> On 28 Nov 2018, at 21:48, Roger Riggs wrote: > > Please review a test cleanup to remove a latent Illegal Reflective Access. > > Adding the @modules was necessary and the code was updated to remove > compilation warnings. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-handlerloo

Re: RFR of JDK-8214431: tests failed because can not find removed library folder at test/jdk/lib/testlibrary/jdk/testlibrary

I think this good. Thanks. -Chris. > On 28 Nov 2018, at 20:32, David Holmes wrote: > > Hi Hamlin, > > On 28/11/2018 10:52 pm, Hamlin Li wrote: >> Hi David, >> Yes, they'd better be removed too, so I create another bug >> https://bugs.openjdk.java.net/browse/JDK-8214435 to track it. > > Ok. >

Re: RFR: 8210454 jar tool does not allow setting the module version without also setting the main class

> On 26 Nov 2018, at 18:41, Lance Andersen wrote: > > The webrev can be found at: > http://cr.openjdk.java.net/~lancea/8210454/webrev.00/ Looks good to me Lance, thanks. -Chris.

Re: RFR: 8213921: Use {@systemProperty} tag for properties listed in "Networking Properties"

Priya, On 27/11/2018 08:46, Priya Lakshmi Muthuswamy wrote: Hi, Kindly review the fix for https://bugs.openjdk.java.net/browse/JDK-8213921 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8213921/webrev.00/ I think this is a good change. I built your proposed patch and was pleasantly surprise

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. Righ

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 CSR

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: [12] RFR: 8213301 - Fix legal headers in jdk logging tests

> On 2 Nov 2018, at 15:38, Daniel Fuchs wrote: > > Hi, > > Following Chris's lead in the network area, and Jon’s lead > in the langtools area, here is a change to remove the > "Classpath exception” from several test in the > test/jdk logging area. > > 8213301: Fix legal headers in jdk logging

Re: [12] RFR: 8212941: Loosen the range of JapaneseEra

> On 30 Oct 2018, at 17:45, Naoto Sato wrote: >> .. >> Suggest: "The defined ** era’s {@link #getValue} ** is expected >> to have a consecutive integer associated with it.” >> I suspect that the wording here has deliberately chosen, but I >> wonder if it could be tightened a little? >> `value

Re: [12] RFR: 8212941: Loosen the range of JapaneseEra

> On 30 Oct 2018, at 17:03, Roger Riggs wrote: > > Hi Naoto, > > Looks fine. The wording should allow future Japanese era to be defined > without > the timing being tightly coupled to java specification updates. +1 Suggest: "The defined ** era’s {@link #getValue} ** is expected to have

Re: RFR [12] 8212001: Verify exported symbols in java.base (libjava)

> On 11 Oct 2018, at 13:28, Pavel Rappo wrote: > > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8212001/webrev.00 > This looks good. Thanks Pavel. -Chris.

RFR 8211922: Remove test/jdk/javax/naming/module/RunBasic.java from the ProblemList

Now that 8211921 has been fixed, this test can be removed from the ProblemList. Several hundred test runs have been stable. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -874,8 +874,6 @@ javax/rmi/ssl/SSLSocket

Re: RFR [12] - 8211960: broken links in java.util.logging

On 10/10/18 11:39, Daniel Fuchs wrote: Hi, Please find below a doc-only fix for: 8211960: broken links in java.util.logging https://bugs.openjdk.java.net/browse/JDK-8211960 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html Looks good. -Chris.

RFR [12] 8211920: Close server socket and cleanups in test/jdk/javax/naming/module/RunBasic.java

When the test fails sometimes the output is truncated, or even absent, as the test's sub-process does not complete. This may happen if the client-side encounters an issue and leaves the non-daemon server-side thread blocked in accept. The test should close the server socket when the client-side com

RFR [12] 8211863: Problem list test/jdk/javax/naming/module/RunBasic.java

Can I get a review to add javax/naming/module/RunBasic.java to the ProblemList until we can resolve 8211850. This test has been failing intermittently for months now. $ hg diff test/jdk/ProblemList.txt diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt

Re: RFR: 8211765 - JarFile constructor throws undocumented exception

Looks good. -Chris > On 6 Oct 2018, at 14:50, Lance Andersen wrote: > > Hi All > > I integrated and tested Jaikiran’s patch. I made a minor change to the > test. The webrev can be found at > > http://cr.openjdk.java.net/~lancea/8211765/webrev.00/ >

Re: JarFile constructor throws undocumented exception (only) on Windows OS

> On 5 Oct 2018, at 14:58, Alan Bateman wrote: > >> On 05/10/2018 12:06, Chris Hegarty wrote: >> >> Given the stacktrace, from a previous email in this thread, >> does it make more sense to wrap the IPE in an IOException, >> rather then declaring that the

Re: JarFile constructor throws undocumented exception (only) on Windows OS

> On 5 Oct 2018, at 12:08, Jaikiran Pai wrote: > >> I don't have access to create an issue for this in OpenJDK JIRA, so I'll >> go ahead and create one at bugs.java.com. >> > I just submitted the report. Internal review id 9057522 has been > assigned to the issue. And now in the JDK project:

Re: JarFile constructor throws undocumented exception (only) on Windows OS

On 05/10/18 11:45, Alan Bateman wrote: On 04/10/2018 10:36, Jaikiran Pai wrote: : The javadoc of JarFile constructor(s) mentions that:   * @throws IOException if an I/O error has occurred Given that the javadoc doesn't mention anything about this other exception, would this throwing of j

Re: RFR[12] JDK-8211107: LDAPS communication failure with jdk 1.8.0_181

> On 2 Oct 2018, at 02:09, Prasadrao Koppula > wrote: > > .. > Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ Looks good. -Chris.

Re: RFR: jsr166 integration 2018-09

> On 26 Sep 2018, at 19:53, Martin Buchholz wrote: > > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html > > 8210971: Add exception handling methods to CompletionStage and > CompletableFuture > https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/e

Re: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList

Looks good. -Chris. > On 24 Sep 2018, at 17:56, Daniel D. Daugherty > wrote: > > Greetings, > > The following bug was used to ProblemList a couple of tests: > > JDK-8209018 ProblemList tests affected by JDK-8208690 > https://bugs.openjdk.java.net/browse/JDK-8209018 > > Jon's fix for

Re: [12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"

n", > client.getLocalPort()); > client.connect(svr.getHost(), svr.getPort()); > pendingSockets.add(new NamedWeak(client, pendingQueue, > "clientMulticastSocket")); > extractRefs(client, "clientMulticastSocket"); > > Regards, &g

Re: [12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"

Thank you for looking at this issue Chris Y. I don’t disagree with the changes, but if you want to confirm your suspicion, that the same port is being reused, then printing out the client’s bound port would do that ( since the servers port is already printed in the logs ). If such a change was i

Re: RFR - JDK-8202442 - String::unescape (Code Review)

> On 19 Sep 2018, at 23:21, Stuart Marks wrote: > > ... > > 2979 * Each unicode escape in the form \u is translated to the > 2980 * unicode character whose code point is {@code 0x}. Care should > be > 2981 * taken when using UTF-16 surrogate pairs to ensure that the hig

Re: RFR (12): 8210819: Update the host name in CNameTest.java

Looks fine Frank. Thanks, -Chris. On 17/09/18 08:12, Frank Yuan wrote: Hi Would you like to review the following patch for Bug: https://bugs.openjdk.java.net/browse/JDK-8210819 --- a/test/jdk/sun/net/InetAddress/nameservice/dns/CNameTest.java Wed Sep 12 21:56:59 2018 -0700

Re: 8207690: Parsing API for classpath and similar path strings

> On 11 Sep 2018, at 14:18, Roger Riggs wrote: > > Hi Chris, > > On 9/11/18 7:50 AM, Chris Hegarty wrote: >>> On 11 Sep 2018, at 10:24, Alan Bateman wrote: >>> >>> On 10/09/2018 21:55, Roger Riggs wrote: >>>> Nope! there'

Re: 8207690: Parsing API for classpath and similar path strings

> On 11 Sep 2018, at 10:24, Alan Bateman wrote: > > On 10/09/2018 21:55, Roger Riggs wrote: >> Nope! there's quoting on Windows that gets short changed with that work >> around. >> >> Other opinions?, Suggestions? > One suggestion is reduce this down to one method that returns a stream rather

Re: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection

> On 11 Sep 2018, at 09:50, vyom tewari wrote: > > Hi Chris,Daniel, > > Please find the latest patch( > http://cr.openjdk.java.net/~vtewari/8205330/webrev0.1/index.html ). Thanks Vyom, Reviewed. -Chris.

Re: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection

, Chris Hegarty wrote: Vyom, The NPE is originating from the finally block of the LdapClient `authenticate` method. In the finally block there is an attempt to restore the "read" timeout, since it was changed earlier in `authenticate`, to reflect the connect timeout value, since the

Re: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection

Vyom, The NPE is originating from the finally block of the LdapClient `authenticate` method. In the finally block there is an attempt to restore the "read" timeout, since it was changed earlier in `authenticate`, to reflect the connect timeout value, since the subsequent operation(s) are consider

Re: [12] RFR 8042902: Test java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java fails intermittently

l call InetAddress.getHostName() first to set > holder() ’s hostname field in testAllNetworkInterfaces() before serialization > test (as Chris Hegarty commented in 2014. And per Mark's comments, "display > call was commented out as it was too verbose" so we just simple pri

Re: RFR(M) : 8210039 : move OSInfo to top level testlibrary

Igor, > On 31 Aug 2018, at 19:42, Igor Ignatyev wrote: > > Alan, Chris, > > thanks for looking at it, I went w/ the alternative suggested by Chris. that > required a sprinkle of doPrivileged in the testlibrary, but now > Sockets/policy.* files grant the minimal required permissions to the tes

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Rob, > On 3 Sep 2018, at 22:48, Rob McKenna wrote: > > Hi folks, > > I'd like to get a re-review of this change: > > https://bugs.openjdk.java.net/browse/JDK-8139965 > This issue is closed as `will not fix`. I presume you will re-open it bef

Re: RFR(M) : 8210039 : move OSInfo to top level testlibrary

> On 30 Aug 2018, at 08:51, Alan Bateman wrote: > > On 28/08/2018 17:50, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8210039/webrev.00/index.html >>> 698 lines changed: 114 ins; 240 del; 344 mod >> Hi all, >> >> could you please review this clean up of jdk testlibrary? >> th

Re: RFR:8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection

Hi Vyom, On 24/08/18 11:35, vyom tewari wrote: Hi All, Please review this simple fix below webrev: http://cr.openjdk.java.net/~vtewari/8205330/webrev0.0/index.html bugid: https://bugs.openjdk.java.net/browse/JDK-8205330 This fix will resolve the race in LdapClient  where we are explicitly m

Re: RFR: JDK-8176553 LdapContext follows referrals infinitely ignoring set limit

> On 20 Aug 2018, at 12:29, Vyom Tewari wrote: > > On 8/20/2018 4:19 PM, Chris Hegarty wrote: >>> On 19 Aug 2018, at 12:51, vyom tewari wrote: >>> >>> Hi, >>> >>> Please review the below code change. >>> >>> W

Re: RFR: JDK-8176553 LdapContext follows referrals infinitely ignoring set limit

> On 19 Aug 2018, at 12:51, vyom tewari wrote: > > Hi, > > Please review the below code change. > > Webrev : http://cr.openjdk.java.net/~vtewari/8176553/webrev0.0/index.html > > bugid: https://bugs.openjdk.java.net/browse/JDK-8176553 > > Our all internal tests are clean, this patch is

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

s 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: 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 > infor

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. Nothing

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 complex

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

> On 19 Jul 2018, at 13:54, Chris Hegarty wrote: > > > I filed the following issue to generalize the `includeInExceptions` security > property: > https://bugs.openjdk.java.net/browse/JDK-8207846 I sent out an RFR for 8207846, since I think it is worth proceeding with

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

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

> On 19 Jul 2018, at 15:42, Sean Mullan wrote: > >> ... > > Note that making this a security property for all general cases may have > performance implications in certain scenarios since the java.security file > will need to be loaded and fully parsed before it can be used. If you are > alr

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

> On 19 Jul 2018, at 11:46, Alan Bateman wrote: > > On 19/07/2018 09:07, Baesken, Matthias wrote: >> Hello, in the meantime I prepared a CSR : >> >> https://bugs.openjdk.java.net/browse/JDK-8207768 >> >> >>> jdk.includeInExceptions expands the scope. That might be okay but we >>> will need

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

> On 19 Jul 2018, at 09:07, Baesken, Matthias wrote: > > Hello, in the meantime I prepared a CSR : > > https://bugs.openjdk.java.net/browse/JDK-8207768 This CSR seems a little premature. Matthias said: "However so far it is still a bit unclear how many exceptions we would like to enhance ,

Re: BiCollector

> On 18 Jun 2018, at 22:29, Brian Goetz wrote: > > "bisecting" sounds like it sends half the elements to one collector and half > to the other ... > > "tee" might be a candidate, though it doesn't follow the `ing convention. > "teeing" sounds dumb. Doesn’t follow the convention either, bu

Re: RFR: JDK-8203891: Upgrade JOpt Simple to 5.0.4

On 31/05/18 10:11, Jan Lahoda wrote: Hi, I'd like to upgrade the JOpt Simple library we are using to version 5.0.4. Bug: https://bugs.openjdk.java.net/browse/JDK-8203891 Complete webrev: http://cr.openjdk.java.net/~jlahoda/8203891/webrev.00/complete/ Delta webrev only showing (all) JDK cha

Re: RFR 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes

Alan, On 25/05/18 12:27, Alan Bateman wrote: On 24/05/2018 21:57, Ivan Gerasimov wrote: .. WEBREV: http://cr.openjdk.java.net/~igerasim/8203369/00/webrev/ The changes in 01/webrev look okay to me but I'm curious if there are any ports in OpenJDK where the values are different. HPUX 11.31 (

Re: RFR: CSR - JDK-8203428 Predicate::not

On 18/05/18 17:35, Jim Laskey wrote: Introduce a new static method Predicate::not which will allow developers to negate predicate lambdas trivially. csr: https://bugs.openjdk.java.net/browse/JDK-8203428 I have looked for this a number of times. +1 -Chris.

Re: 8202284: FileChannel and FileOutpuStream variants of AtomicAppend should pass silently on macOS >= 10.13

> On 25 Apr 2018, at 23:11, Brian Burkhalter > wrote: > > Issue:https://bugs.openjdk.java.net/browse/JDK-8202284 > Patch:http://cr.openjdk.java.net/~bpb/8202284/webrev.00/ I think this looks good Brian. > On 26 Apr 2018, at 01:09, Brian Burkhalter > wrote: > > https://bugs.

Re: InetAddress.getByName/getAllByName for empty host string

patch. A patch containing the specification clarification and an update to an existing test to cover said specification clarification would be helpful. The change will require a CSR, but I can do that on your behalf. -Chris. -Jaikiran On 13/04/18 8:41 PM, Chris Hegarty wrote: Hi Jaikiran, On

Re: RFR: 8184693: (opt) add Optional.isEmpty

> On 15 Apr 2018, at 11:25, Vivek Theeyarath > wrote: > > Hi All, >Please review http://cr.openjdk.java.net/~vtheeyarath/8184693/webrev.01/ This looks ok to me. For consistency, can you please update the copyright header year range in OptionalInt. -Chris. > Regards > Vivek > -Ori

Re: InetAddress.getByName/getAllByName for empty host string

Hi Jaikiran, On 13/04/18 15:29, Jaikiran Pai wrote: The javadoc of InetAddress.getByName(host) and getAllByName(host) states that: If the host is null then an InetAddress representing an address of the loopback interface is returned. For non-null values the javadoc explains what the impleme

Re: 8200449: ReadAllReadNTransferTo fails occasionally

+1 -Chris. > On 29 Mar 2018, at 20:01, Brian Burkhalter > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8200449 > > Problem is due to passing zero to Random.nextInt(int). Diff included below. > > Thanks, > > Brian > > --- a/test/jdk/java/io/ByteArrayInputStream/ReadAllReadNTransferTo

Re: RFR: {@docRoot} reference need to be updated to reflect new module structure

> On 27 Mar 2018, at 01:01, Jonathan Gibbons > wrote: > > This is fixing up some links in the java.base module, following a recent > change > in javadoc to the organization of the generated files. While the change was > mostly > transparent, links within the documentation using {@docRoot} nee

Re: RFR 8193033 remove terminally deprecated sun.misc.Unsafe.defineClass

> On 15 Mar 2018, at 17:06, Paul Sandoz wrote: > > Hi, > > Please review this patch to remove sun.misc.Unsafe.defineClass in 11. > > There has been much outreach, by Alan and the Jigsaw team, about its public > replacement MethodHandles.Lookup.defineClass. > > CSR is here: > > https://bugs

Re: RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass

On 14/03/18 13:08, Alan Bateman wrote: On 14/03/2018 12:56, Chris Hegarty wrote: This is a review request to remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass. JDK-8179424 removed terminally deprecated jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these

RFR 8199464 [11] Remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass

This is a review request to remove remaining vestiges of Java_sun_reflect_Reflection_getCallerClass. JDK-8179424 removed terminally deprecated jdk.unsupported/sun.reflect.Reflection.getCallerClass(int), these references are to the no-args getCallerClass that was removed a long time ago. These

Re: RFR: JDK-8144300 : Java does not honor http.nonProxyHosts value having wildcard * both at end and start

Pallavi, On 01/03/18 14:46, Pallavi Sonal wrote: Hi, Please review the following change to fix JDK-8144300. Bug : https://bugs.openjdk.java.net/browse/JDK-8144300 Webrev : http://cr.openjdk.java.net/~rpatil/8144300/webrev.00/ Looks ok to me. Please add the bugId to the @bug tag in the

Re: RFR: 8197538 Remove mention of hotjava paths in MimeTable.java

On 05/03/18 21:32, Roger Riggs wrote: Please review a change to a location where mailcap entries may appear. The mention of "hotjava.home" is ancient history. BTW, if you know whether "user.mailcap" System property is used, I'd be interested if anyone is using it. I may need a CSR to make i

Re: RFR 8195059: Update java.net Socket and DatagramSocket implementations to use Cleaner

On 02/02/18 17:07, Roger Riggs wrote: Hi Chris, Updated in place. http://cr.openjdk.java.net/~rriggs/webrev-net-cleanup-8195059/ Looks good to me. Trivially ( no need to re-generate the webrev ), in windows SocketImpl.c java*_net*_java_net_SocketCleanable -Chris.

Re: RFR 8195059: Update java.net Socket and DatagramSocket implementations to use Cleaner

by retaining the checking for GC reclaimed objects but removed checking fd counts, since they were unreliable in testing and not consistent across OS's Thanks, Roger On 2/1/2018 10:11 AM, Chris Hegarty wrote: Hi Roger, On 31 Jan 2018, at 15:52, Roger Riggs wrote: a

Re: RFR 8195059: Update java.net Socket and DatagramSocket implementations to use Cleaner

Hi Roger, > On 31 Jan 2018, at 15:52, Roger Riggs wrote: > > Adding net-...@openjdk.java.net > > On 1/30/2018 5:08 PM, Roger Riggs wrote: >> Please review changes to replace finalizers in socket, datagram, and >> multicast networking >> with Cleaner based release of the raw file descriptors.

Re: [8u-dev] RFR - 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

> On 26 Jan 2018, at 16:40, Rob McKenna wrote: > > Hi folks, > > I'd like to backport this change to 8u-dev. > > The changes are straightforward enough but 8u needs some changes that > were made to InnocuousThread. (strictly it doesn't need all of the > changes I've made but I've made an effor

Re: RFR 4358774: Add null InputStream and OutputStream

> On 4 Jan 2018, at 23:42, Brian Burkhalter wrote: > >> On Dec 11, 2017, at 12:52 PM, Brian Burkhalter >> wrote: >> >>> On Dec 8, 2017, at 3:12 PM, Brian Burkhalter >>> wrote: >>> >>> All previous suggested changes have been made in >>> >>> http://cr.openjdk.java.net/~bpb/4358774/webrev.0

Re: Fix typo in InetSocketAddress.getAddress() documentation

> On 4 Jan 2018, at 21:29, Brian Burkhalter wrote: > > Hi Chris, > > Sure, no problem: http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html Reviewed. Thank you. -Chris.

Re: Adding SocketChannel toString to connection exception messages

t included in toString) then logging frameworks could detect >> instances of ConnectException and process them accordingly. >> >> Gruss >> Bernd >> -- >> http://bernd.eckenfels.net >> >> From: net-dev o

Re: Adding SocketChannel toString to connection exception messages

On 22/12/17 14:59, Seán Coffey wrote: As someone who works with alot of log files, I'd like to chime in and support Steven's end goal. Looking at a "Connection refused" error in the middle of a log file that possibly extends to millions of lines is near useless. In the era of cloud compute, di

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

On 21/12/17 21:40, mandy chung wrote: ... > ReflectionFactory or other class in sun.reflect package would do it. and create an issue to follow up sun.reflect.Reflection as flagged as a removed API. That’s what the test now does with my changes. Why separate it out into a separate issue? If

Re: Adding SocketChannel toString to connection exception messages

On 22/12/17 01:27, David Holmes wrote: cc'ing net-dev as that might be the more appropriate list. On 22/12/2017 10:59 AM, Steven Schlansker wrote: On Dec 21, 2017, at 4:35 PM, David Holmes wrote: On 22/12/2017 10:29 AM, Steven Schlansker wrote: On Dec 21, 2017, at 11:11 AM, Steven Schlansk

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

> On 21 Dec 2017, at 16:09, mandy chung wrote: > >>> ... >> The test is about identifying StackWalker as the replacement >> supported API for getCallerClass, which is continues to do. >> I could add yet another scenario to test for a different internal >> API that also has a replacement, and add

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

> On 21 Dec 2017, at 12:33, David Holmes wrote: > ... >> The test is about identifying StackWalker as the replacement >> supported API for getCallerClass, which is continues to do. > > Won't pretend I actually understand that, but as long as the test works > reliably then okay. Jdeps prints he

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

David, Alan, > On 21 Dec 2017, at 09:54, Alan Bateman wrote: > > On 21/12/2017 09:29, David Holmes wrote: >> : >>> >>> Updated webrev: >>>http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ >> >> I don't quite follow the change to the langtools test. Is it just trying to >> reference so

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

David, > On 21 Dec 2017, at 00:42, David Holmes wrote: > > Hi Chris, > > Adding in hotspot-runtime-dev now that you have included the VM side of the > cleanup. What repo are you planning on pushing this to? Since there are now changes in the hotspot area, then it probably makes sense to push

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

> On 20 Dec 2017, at 19:21, mandy chung wrote: > > The native side and hotspot side should also be cleaned up. Good call. I think the following is probably as far as we want to go. Maybe a follow-on issue could be filed if deeper VM clean up is needed? http://cr.openjdk.java.net/~chegar/81794

RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

In JDK 9 sun.reflect.Reflection.getCallerClass, and its jdk.internal counterpart, where both deprecated-for-removal ( to give prior warning of the unsupported private API's intended removal ). The supported replacement, since Java SE 9, is java.lang.StackWalker. http://cr.openjdk.java.net/~chegar

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

On 19/12/17 23:22, Brian Burkhalter wrote: .. Updated version here: http://cr.openjdk.java.net/~bpb/8193832/webrev.02/ Looks good to me. This is a nice improvement on the original implementation that I added in 9. Thanks. -Chris.

Re: RFR: jsr166 jdk integration 2017-12-XX

++1 -Chris > On 7 Dec 2017, at 18:03, Paul Sandoz wrote: > > +1 > > Paul. > >> On 7 Dec 2017, at 09:14, Martin Buchholz wrote: >> >> http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html >> >> With the change to the openjdk release model, jsr166 integrations will

RFR - 8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride

Currently JDK code that wants to create innocuous threads is required to do so within a privileged context that has the "enableContextClassLoaderOverride" RuntimePermission ( since the InnocuousThread class overrides setContextClassLoader ). This permissions should not be required, especially if

Re: RFR 8145635 : Add TCP_QUICKACK socket option

; incorporated review comments from you and re-base the patch to our > consolidated repo(jdk10/master). > > Thanks, > > Vyom > > > On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote: >> Vyom, >> >>> On 11 Sep 2017, at 16:38, vyom tewari wr

<    1   2   3   4   5   6   7   8   9   10   >