Re: RFR 8196740 : Character.digit(int,int) returns wrong value for out of range radix

After some experimentation, I couldn't find anything faster than the variant with the check (value >= 0), so let's go ahead with it. Here's the updated webrev: http://cr.openjdk.java.net/~igerasim/8196740/01/webrev/ With kind regards, Ivan On 2/2/18 5:47 PM, Claes Redestad wrote: Hi Ivan,

Re: RFR 8196740 : Character.digit(int,int) returns wrong value for out of range radix

On 2/2/18 6:36 PM, Ivan Gerasimov wrote: On 2/2/18 5:47 PM, Claes Redestad wrote: Hi Ivan, On 2018-02-03 02:14, Ivan Gerasimov wrote: Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8196740 WEBREV: http://cr.openjdk.java.net/~igerasim/8196740/00/webr

Re: RFR 8196740 : Character.digit(int,int) returns wrong value for out of range radix

On 2/2/18 5:47 PM, Claes Redestad wrote: Hi Ivan, On 2018-02-03 02:14, Ivan Gerasimov wrote: Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8196740 WEBREV: http://cr.openjdk.java.net/~igerasim/8196740/00/webrev/ yes, an obvious error in hindsight!

Re: RFR 8196740 : Character.digit(int,int) returns wrong value for out of range radix

Hi Ivan, On 2018-02-03 02:14, Ivan Gerasimov wrote: Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8196740 WEBREV: http://cr.openjdk.java.net/~igerasim/8196740/00/webrev/ yes, an obvious error in hindsight! I suspect that this version may even work

RFR 8196740 : Character.digit(int, int) returns wrong value for out of range radix

Hello! The recent fix for JDK-8196331 [1] appeared to slightly change the behavior. Specifically, if the radix is greater than MAX_RADIX then the method may return a non-negative value, even though the spec requires it must return -1 [2]. [1] https://bugs.openjdk.java.net/browse/JDK-8196331 [

Re: [PATCH] Reduce Chance Of Mistakenly Early Backing Memory Cleanup

Hi, I have one question, maybe stupid. I'm wondering about one situation. Suppose you have this Java code: void m() {     // code before...     Objects.requireNonNull(this); } Of course, the non-null check will never throw NPE. The check will most likely even be optimized away by JIT. But i

[PATCH] Fix compiler warnings with newer GCC 7.2.1

This patch fixes a few of the compiler warnings when using gcc 7.2.1. In general there are many other warnings (a majority of which are implicit fallthrough warnings in jdk.crypto.ec package's ecp_*.c files and java.desktop package's splashscreen_gfx_impl.h file). I can post them if there is in

Re: RFR: 8196609: Improve javadoc for java.time.Instant.getEpochSecond

Hi Martin, Looks good to me! cheers, -- daniel On 02/02/18 21:14, Martin Buchholz wrote: The nanos *are* hard to describe non-confusingly - resisting the urge to fix more globally. --- a/src/java.base/share/classes/java/time/Instant.java +++ b/src/java.base/share/classes/java/time/Instant.ja

RFR: 8196609: Improve javadoc for java.time.Instant.getEpochSecond

The nanos *are* hard to describe non-confusingly - resisting the urge to fix more globally. --- a/src/java.base/share/classes/java/time/Instant.java +++ b/src/java.base/share/classes/java/time/Instant.java @@ -610,7 +610,7 @@ * * The epoch second count is a simple incrementing count o

Re: RFR (JDK10/JAXP Doc-only) 8196717: remove xmlresolver.md

Thanks Lance, Roger! Best, Joe On 2/2/2018 12:44 PM, Lance Andersen wrote: go for it On Feb 2, 2018, at 3:36 PM, Joe Wang > wrote: Hi, Refer to JDK-8177561[1], XML Commons Resolver was removed from JDK 10. xmlresolver.md therefore needs to be removed as well.

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Thanks Jason. Will update that accordingly. Best, Joe On 2/2/2018 11:22 AM, Jason Mehrens wrote: Joe, The identity check in CS.compare makes sense. However, it won't be null hostile if we call CS.compare(null, null) and that doesn't seem right. Usually when writing comparator classes I end u

Re: RFR (JDK10/JAXP Doc-only) 8196717: remove xmlresolver.md

go for it > On Feb 2, 2018, at 3:36 PM, Joe Wang wrote: > > Hi, > > Refer to JDK-8177561[1], XML Commons Resolver was removed from JDK 10. > xmlresolver.md therefore needs to be removed as well. > > Please review: > https://bugs.openjdk.java.net/browse/JDK-8196717 > http://cr.openjdk.java.net

Re: RFR (JDK10/JAXP Doc-only) 8196717: remove xmlresolver.md

+1 On 2/2/2018 3:36 PM, Joe Wang wrote: Hi, Refer to JDK-8177561[1], XML Commons Resolver was removed from JDK 10. xmlresolver.md therefore needs to be removed as well. Please review: https://bugs.openjdk.java.net/browse/JDK-8196717 http://cr.openjdk.java.net/~joehw/jdk10/8196717/webrev/ [1

RFR (JDK10/JAXP Doc-only) 8196717: remove xmlresolver.md

Hi, Refer to JDK-8177561[1], XML Commons Resolver was removed from JDK 10. xmlresolver.md therefore needs to be removed as well. Please review: https://bugs.openjdk.java.net/browse/JDK-8196717 http://cr.openjdk.java.net/~joehw/jdk10/8196717/webrev/ [1] https://bugs.openjdk.java.net/browse/JDK

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

Hi Peter, I filed a new issue for the cleanup:    https://bugs.openjdk.java.net/browse/JDK-8196716 On 2/2/2018 1:16 PM, Peter Levart wrote: Hi Roger, Nice separation of concerns (io vs. net). Is JavaIOFileDescriptorAccess.registerCleanup(FileDescriptor) currently used at all? I have not gott

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Joe, The identity check in CS.compare makes sense. However, it won't be null hostile if we call CS.compare(null, null) and that doesn't seem right. Usually when writing comparator classes I end up with: === if (Objects.requireNonNull(o1) == Objects.requireNonNull(o2)) { return 0; } === Jaso

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Hi, Thanks all for comments and suggestions. I've updated the webrev. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8137326 webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/ Thanks, Joe On 1/31/2018 9:31 PM, Joe Wang wrote: Hi Tagir, Thanks for the comment. I w

Re: JDK-6372077: JarFile.getManifest() should handle manifest attribute names up to 70 bytes

Hi Roger Glad to send the patch. I also tried to write a meaningful and useful test. Please tell me ruthlessly if it makes sense or what not. Looking forward to progress in a bug that has been open for more than 10 years now. Philipp On 22.01.2018 21:03, Roger Riggs wrote: Hi Philipp, I'm

Re: [JDK 11] RFR 8195981: Move some tests to OpenJDK for jdk_lang test group

On 2/2/18 7:02 AM, Amy Lu wrote: Please review the patch to move some tests to OpenJDK for jdk_lang test group. bug: https://bugs.openjdk.java.net/browse/JDK-8195981 webrev: http://cr.openjdk.java.net/~amlu/8195981/webrev.00/ I suggest to merge jdk/vm/misc and jdk/vm/monitor directory and

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

Hi Roger, Nice separation of concerns (io vs. net). Is JavaIOFileDescriptorAccess.registerCleanup(FileDescriptor) currently used at all? Although not necessary for this patch, but to make code more symmetric, FileDecriptor.FDCleaner could also be extracted into a package-private top class a

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

Hi Chris, Updated in place.   http://cr.openjdk.java.net/~rriggs/webrev-net-cleanup-8195059/ Thanks, Roger On 2/2/2018 11:30 AM, Chris Hegarty wrote: Roger, On 01/02/18 21:29, Roger Riggs wrote: Hi Chris, Thanks for the review and suggestion. Webrev updated: http://cr.openjdk.java.net/~rr

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

Roger, On 01/02/18 21:29, Roger Riggs wrote: Hi Chris, Thanks for the review and suggestion. Webrev updated: http://cr.openjdk.java.net/~rriggs/webrev-net-cleanup-8195059/ This looks good to me, just a few small comments: 1) windows SocketImpl.c in the comments: java_net_AbstractPlainS

[JDK 11] RFR 8195981: Move some tests to OpenJDK for jdk_lang test group

Please review the patch to move some tests to OpenJDK for jdk_lang test group. bug: https://bugs.openjdk.java.net/browse/JDK-8195981 webrev: http://cr.openjdk.java.net/~amlu/8195981/webrev.00/ Thanks, Amy

Re: RFR: 8196331: Optimize Character.digit for latin1 input

Hi Claes, sorry for the delay, I didn't catch you message before, because you CC'd me which causes that my email filter misses the ListID tag to catch. Thanks for the update, times change with the compact strings feature. Another approach could be to access the String constant via Unsafe. -U

Re: RFR: 8011697(ScriptEngine "js" randomly means either "rhino" or "nashorn", but should instead select one)

On 02/02/2018 08:53, Srinivas Dama wrote: Hi Alan/Sundar, Please review the revised webrev with copyright header change at http://cr.openjdk.java.net/~sdama/8011697/webrev.02/ Looks good.

Re: RFR: 8011697(ScriptEngine "js" randomly means either "rhino" or "nashorn", but should instead select one)

Looks good. -Sundar On 02/02/18, 2:23 PM, Srinivas Dama wrote: Hi Alan/Sundar, Please review the revised webrev with copyright header change at http://cr.openjdk.java.net/~sdama/8011697/webrev.02/ Regards, srinivas -Original Message- From: Sundararajan Athijegannathan Sent: Tuesday,

RE: RFR: 8011697(ScriptEngine "js" randomly means either "rhino" or "nashorn", but should instead select one)

Hi Alan/Sundar, Please review the revised webrev with copyright header change at http://cr.openjdk.java.net/~sdama/8011697/webrev.02/ Regards, srinivas -Original Message- From: Sundararajan Athijegannathan Sent: Tuesday, January 30, 2018 8:53 PM To: core-libs-dev@openjdk.java.net Sub