Re: RFR 8240524: Removed warnings from test classes

2020-03-06 Thread Vyom Tiwari
Hi Vipin, Test code changes looks good to me as well except copyright changes, which will be fix at the time of pushing the code by Christoph. Thanks, Vyom On Fri, Mar 6, 2020 at 12:06 PM Langer, Christoph wrote: > Hi Vipin, > > this all looks correct to me. > > When changing the copyright

Re: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder

2020-03-06 Thread Roger Riggs
Hi Brian, Updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893-1/index.html The threshold is a pretty loose target. Given the original error that leaked a handle for every process started, it just needs to detect a growing number of handles in use.  But for the sake of

Re: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder

2020-03-06 Thread Roger Riggs
Hi Naoto, Updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893-1/index.html I don't think getting handle count of your own process can ever fail. But in the abundance of caution, added a check and failure. Copyright updated. Thanks, Roger Corrected copyright On 3/5/20

Re: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder

2020-03-06 Thread Brian Burkhalter
Hi Roger, Looks good! Brian > On Mar 6, 2020, at 8:16 AM, Roger Riggs wrote: > > Updated webrev: > http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893-1/index.html > > > The threshold is a pretty loose

Re: RFR(S): 8232081: Try to link all classes during dynamic CDS dump

2020-03-06 Thread Calvin Cheung
Hi Ioi, On 3/5/20 9:16 PM, Ioi Lam wrote: Hi Calvin, Looks good. Thanks for taking another look. In JDK-8240244, I removed "ik->loader_type() != 0" because it's unclear what it means. I replaced with a new method InstanceKlass::is_shared_unregistered_class(). I think you can use this in

Re: [8u] PING: RFR: 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs.

2020-03-06 Thread Severin Gehwolf
Hi Andrew, On Tue, 2020-02-18 at 10:58 +, Andrew Hughes wrote: > On 11/10/2019 15:54, Severin Gehwolf wrote: > > On Fri, 2019-10-11 at 16:47 +0200, Mario Torre wrote: > > > Hi Severin, > > > > > > The patch looks good to me. > > > > Thanks for the review, Mario! > > > > Cheers, > > Severin

Re: PING: RFR(s): 8240189: [TESTBUG] Some cgroup tests are failing after JDK-8231111

2020-03-06 Thread Severin Gehwolf
On Fri, 2020-03-06 at 14:52 +, Baesken, Matthias wrote: > Hi Severin, looks good to me too . Thanks for the review! Cheers, Severin > Best regards, Matthias > > > > > Hi, > > > > I still need a *R*eview for this. Any takers? > > > > Thanks, > > Severin > > > > On Fri, 2020-02-28 at

PING: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format

2020-03-06 Thread Chihiro Ito
Hi, I tried to correct this problem. Could you review this fix, please? According to the RFC 4122, UUID has a fixed format. I tried to raise an exception if a string was specified that is not suitable for this format. Also, is there anything else I should be aware of with this bug? Webrev :

RE: PING: RFR(s): 8240189: [TESTBUG] Some cgroup tests are failing after JDK-8231111

2020-03-06 Thread Baesken, Matthias
Hi Severin, looks good to me too . Best regards, Matthias > Hi, > > I still need a *R*eview for this. Any takers? > > Thanks, > Severin > > On Fri, 2020-02-28 at 14:52 +0100, Severin Gehwolf wrote: > > Hi Bob, > > > > On Thu, 2020-02-27 at 15:04 -0500, Bob Vandette wrote: > > > The updates

Re: RFR 8239893: Windows handle Leak when starting processes using ProcessBuilder

2020-03-06 Thread naoto . sato
Looks good. Thanks for the update. Naoto On 3/6/20 8:17 AM, Roger Riggs wrote: Hi Naoto, Updated webrev: http://cr.openjdk.java.net/~rriggs/webrev-handles-8239893-1/index.html I don't think getting handle count of your own process can ever fail. But in the abundance of caution, added a check

Re: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format

2020-03-06 Thread Roger Riggs
Hi  Chihiro, et.al., Thanks for taking a look at this issue,  however... There has been a long history of concerns[1] about breaking existing applications that depend on the loose parsing of UUIDs.  Throwing an exception where it did not previously is an incompatible change. The crucial

Re: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF

2020-03-06 Thread Brian Burkhalter
Thanks, Roger. I’ll let it hang until next week and then file a CSR. Brian > On Mar 6, 2020, at 10:49 AM, Roger Riggs wrote: > > :) Still looks fine. > > On 3/5/20 4:53 PM, Brian Burkhalter wrote: >> Might anyone else have any comments on this thread the original post in >> which was [1]. >>

RFR: 8240629: argfiles parsing broken for argfiles with comment cross 4096 bytes chunk

2020-03-06 Thread Henry Jen
Hi, Please review the webrev[1] fix JDK-8240629 reported earlier by Robert. http://cr.openjdk.java.net/~henryjen/jdk/8240629.0/webrev/ Cheers, Henry

Re: [15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF

2020-03-06 Thread Roger Riggs
:) Still looks fine. On 3/5/20 4:53 PM, Brian Burkhalter wrote: Might anyone else have any comments on this thread the original post in which was [1]. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064417.html On Jan 31, 2020, at 12:21 PM, Brian

Re: PING: RFR: 8216407: java.util.UUID.fromString accepts input that does not match expected format

2020-03-06 Thread Joe Darcy
Hello Chihiro, Note that as the proposed change affects behavioral compatibility, it will need to have CSR review (https://wiki.openjdk.java.net/display/csr/Main) in addition to code review. Reviewers might find it helpful to have a written categorization of the strings this change rejects

Re: 8202469 / 8202473: Correct type annotation resolution for class type variables

2020-03-06 Thread Rafael Winterhalter
I finally found the time to look at this again, sorry for the delay. Thank you for your comments. I had the chance to better look into the problem and simplify the code a bit more and also reduced the scope of the fix to a single problem. I also added test cases that should be exhaustive for all