Re: contribute to core-lib module

Hi, I responded to your other email. David On 5/09/2019 3:31 pm, wrote: Hi, leaders. A few days ago, I report a bug in core lib[1]. According to the contribute document[2], I had send oca to oracle andmy name has been listed onoca[3]. But I still can't push my changes to jdk, can

Re: RFR 8230365 : Pattern for a control-char matches non-control characters

Hallo, Since not all combinations make sense (Exception+convert) a multi value might be better: jdk.regex.control=WARN|EXCEPTION|STANDARD|LEGACY With Exception generating an error, Standard beeing the planned new default (treating upper/lower same and error on all undefined chars) and legacy

回复： what to do next to fix JDK-8230557. thanks

hi, developers. Can someone help me? thanks very much !! --原始邮件-- 发件人:"David Holmes"http://openjdk.java.net/contribute/ and you would seem to be up to step 2. :) Cheers, David [1]https://bugs.openjdk.java.net/browse/JDK-8230557

Re: what to do next to fix JDK-8230557. thanks

On 5/09/2019 3:35 pm, 未来阳光 wrote: Hi, leaders. Hi, No "leaders" here only developers :) A few days ago, I report a bug in core lib[1]. According to the contribute document[2], I had send oca to oracle andmy name has been listed onoca[3]. Welcome aboard! But I still can't push my

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hi Dan, With my CSR Group member hat on On 5/09/2019 8:06 am, Daniel D. Daugherty wrote: Brent, You currently have '-XX:+ClassForNameDeferLinking' as a 'product' option, but product options are harder to remove down the road. Would it be better as a diagnostic option? A diagnostic

what to do next to fix JDK-8230557. thanks

Hi, leaders. A few days ago, I report a bug in core lib[1]. According to the contribute document[2], I had send oca to oracle andmy name has been listed onoca[3]. But I still can't push my changes to jdk, can someone tell me how to do next? thanks very match!!

contribute to core-lib module

Hi, leaders. A few days ago, I report a bug in core lib[1]. According to the contribute document[2], I had send oca to oracle andmy name has been listed onoca[3]. But I still can't push my changes to jdk, can someone tell me how to do next? thanks very match!!

Re: RFR 8230365 : Pattern for a control-char matches non-control characters

Thanks, Ivan. We're mostly in agreement. + * If {@code true} then lower-case control-character ids are mapped to the + * their upper-case counterparts. Extra "the". After all these decades I only now realize that c ^= 0x40 moves '?' to the end of the ASCII range and all the other

Re: RFR 8230365 : Pattern for a control-char matches non-control characters

Thank you Martin! On 8/30/19 6:19 PM, Martin Buchholz wrote: There's a strong expectation that ctrl-A and ctrl-a both map to \u0001, so I support Ivan's initiative. I'm surprised java regex gets this wrong. Might need a transitional system property. Right.  I think it would be best to

Re: 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

> On Aug 31, 2019, at 12:28 AM, Alan Bateman wrote: > > On 13/08/2019 22:28, Brian Burkhalter wrote: >> Reprising discussion of [1] from last month. I updated the patch [2] which >> now hopefully accounts for the various comments. Specifically the >> specification of the

Re: RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Brent, You currently have '-XX:+ClassForNameDeferLinking' as a 'product' option, but product options are harder to remove down the road. Would it be better as a diagnostic option? A diagnostic option requires '-XX:+UnlockDiagnosticVMOptions' to be specified before it can be used, e.g.:    

Re: RFR [14/java.xml] 8228854: Default ErrorListener reports warnings and errors to the console

Thanks Lance!  I did a re-run of all tests and they all passed. -Joe On 9/4/19 12:12 PM, Lance Andersen wrote: Hi Joe +1 On Sep 4, 2019, at 1:30 PM, Joe Wang > wrote: Please review a patch that removes some warnings and errors printed out to the console.

RFR: 8212117 : Class.forName may return a reference to a loaded but not linked Class

Hi, Please review my fix for JDK-8212117[1]. The webrev is here: http://cr.openjdk.java.net/~bchristi/8212117/webrev09/ There is also a CSR[2] in need of review. The spec for the 2-arg and 3-arg Class.forName() methods states they will "locate, load, and link" the class, however the linking

Re: [14] RFR: 8229831: Upgrade Character.isUnicodeIdentifierStart/Part() methods to the latest standard

Thanks, Roger. I will drop all occurrences of "solely" and finalize the CSR. Naoto On 9/4/19 1:54 PM, Roger Riggs wrote: Hi Naoto, The CSR looks ok. In Character.java: In the descriptions mentioning VERTICAL TILDE, I would drop the word "solely". for example, * {@code 'VERTICAL TILDE'}

Re: [14] RFR: 8229831: Upgrade Character.isUnicodeIdentifierStart/Part() methods to the latest standard

Hi Naoto, The CSR looks ok. In Character.java: In the descriptions mentioning VERTICAL TILDE, I would drop the word "solely". for example, * {@code 'VERTICAL TILDE'} is added to {@code Start} for backward * compatibility. Overall looks like a good update. Roger On 8/29/19 3:42 PM,

Re: Comments on jpackage (JEP 343)

Hi Sverre, Thank you for your feedback. I've filed [1] bug to address Debian packaging issue. As for your question regarding release number, it is not supported by WiX on Windows. See [2]. Also product version string should follow quite strict rules [3]. However you can encode release value

Re: RFR: JDK-8223211: Remove old code from service support

looks good. /Andy On 8/30/2019 7:44 PM, Alexander Matveev wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). 1) This file is not used and was removed. 2) This file was removed due to

Re: RFR: JDK-8229840: Add jtreg test for --linux-app-category option

looks ok /Andy On 8/30/2019 5:55 PM, Alexey Semenyuk wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - added jtreg test for --linux-app-category option; - added jtreg test for

Re: RFR [14/java.xml] 8228854: Default ErrorListener reports warnings and errors to the console

Hi Joe +1 > On Sep 4, 2019, at 1:30 PM, Joe Wang wrote: > > Please review a patch that removes some warnings and errors printed out to > the console. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228854 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8228973 > > webrev:

Re: jdk-14-jpackage+1-33 on jdk.java.net

This is easily reproducable by putting amperstand in --vendor value on windows. will investigate. /Andy On 9/4/2019 8:05 AM, Sverre Moe wrote: Running WiX failed. The problem it seems is the -dJpAppVendor. It cannot handle special characters in the vendor name. Our company name uses the

Re: jdk-14-jpackage+1-33 on jdk.java.net

This is easily reproducible by putting ampersand in --vendor value on windows. will investigate. /Andy On 9/4/2019 8:05 AM, Sverre Moe wrote: Running WiX failed. The problem it seems is the -dJpAppVendor. It cannot handle special characters in the vendor name. Our company name uses the

Re: RFR(s): 8228580: DnsClient TCP socket timeout

* Pavel Rappo: >> On 4 Sep 2019, at 18:54, Florian Weimer wrote: >> >> You should use a larger timeout than the initial UDP timeout, >> though. > > Could you elaborate on that? If you use the initial UDP timeout (one second, I think), the kernel will not complete the TCP handshake if the

Re: RFR(s): 8228580: DnsClient TCP socket timeout

> On 4 Sep 2019, at 18:54, Florian Weimer wrote: > > You should use a larger timeout than the initial UDP timeout, > though. Could you elaborate on that?

Re: RFR(s): 8228580: DnsClient TCP socket timeout

On 04/09/2019 18:52, Pavel Rappo wrote: You are right, it definitely is a blocking operation. I missed it. I was focused on 712 sock.setSoTimeout(timeoutLeft); So I'd suggest we use explicit connect with timeout java.net.Socket#connect(java.net.SocketAddress, int) Are you

Re: RFR(s): 8228580: DnsClient TCP socket timeout

* Pavel Rappo: >> On 4 Sep 2019, at 18:38, Florian Weimer wrote: >> >> >> >> Maybe I'm mistaken, but I think this: >> >> 692 Tcp(InetAddress server, int port, int timeout) throws IOException { >> 693 sock = new Socket(server, port); >> 694 sock.setTcpNoDelay(true); >> 695

Re: RFR(s): 8228580: DnsClient TCP socket timeout

> On 4 Sep 2019, at 18:38, Florian Weimer wrote: > > > > Maybe I'm mistaken, but I think this: > > 692 Tcp(InetAddress server, int port, int timeout) throws IOException { > 693 sock = new Socket(server, port); > 694 sock.setTcpNoDelay(true); > 695 out = new

Re: RFR(s): 8228580: DnsClient TCP socket timeout

* Pavel Rappo: >> On 4 Sep 2019, at 17:35, Florian Weimer wrote: >> >> * Milan Mimica: >> >>> Continuing in a new thread with a RFR of my own: >>> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ >> >> I would add a comment why there's no explicit TCP connection timeout in >> the code.

RFR [14/java.xml] 8228854: Default ErrorListener reports warnings and errors to the console

Please review a patch that removes some warnings and errors printed out to the console. JBS: https://bugs.openjdk.java.net/browse/JDK-8228854 CSR: https://bugs.openjdk.java.net/browse/JDK-8228973 webrev: http://cr.openjdk.java.net/~joehw/jdk14/8228854/webrev/ Thanks, Joe

Re: RFR(s): 8228580: DnsClient TCP socket timeout

> On 4 Sep 2019, at 17:35, Florian Weimer wrote: > > * Milan Mimica: > >> Continuing in a new thread with a RFR of my own: >> http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ > > I would add a comment why there's no explicit TCP connection timeout in > the code. I assume you rely on the

Re: RFR(s): 8228580: DnsClient TCP socket timeout

> On 4 Sep 2019, at 13:26, Milan Mimica wrote: > > Hello > > Continuing in a new thread with a RFR of my own: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ Here's the link to the previous discussion: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061918.html

Re: RFR(s): 8228580: DnsClient TCP socket timeout

* Milan Mimica: > Continuing in a new thread with a RFR of my own: > http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ I would add a comment why there's no explicit TCP connection timeout in the code. I assume you rely on the TCP stack having its own timeout, right? But I think it can be

RFR(s): 8228580: DnsClient TCP socket timeout

Hello Continuing in a new thread with a RFR of my own: http://cr.openjdk.java.net/~mmimica/8228580/webrev.00/ It has the fixes applied from the first review of the patch. The test was sporadically failing not because of missing synchronization, but more likely because test was not waiting for

Re: jdk-14-jpackage+1-33 on jdk.java.net

Running WiX failed. The problem it seems is the -dJpAppVendor. It cannot handle special characters in the vendor name. Our company name uses the ampersand (&) instead of "and". Caused by: java.io.IOException: Exec failed with code 104 command [[C:\Program Files (x86)\WiX Toolset

Re: Comments on jpackage (JEP 343)

I tired the latest build 14-jpackage+1-35 today. Good to see that debian package file name is finally up to the specification. Noticed something though with building the debian package: When using a control file from the resource directory, jpackage does not use its version and release. Must

RFR of JDK-8134599: Improve the code coverage for ThreadLocal

Would you please review the following patch? bug: https://bugs.openjdk.java.net/browse/JDK-8209824 webrev: http://cr.openjdk.java.net/~mli/8209824/webrev.00/ Thank you -Hamlin