Re: [9] RFR of 8143394: PushbackReader throws NullPointerException

On 08/12/2015 17:22, Brian Burkhalter wrote: : An updated version with “while” instead of “if” is here: http://cr.openjdk.java.net/~bpb/8143394/webrev.02/ Looks okay to me now. -Alan

Re: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration)

Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8032510/webrev.03/ Regards, Nadeesh TV On 12/11/2015 4:45 PM, Stephen Colebourne wrote: Missing blank line after the new method. Typo: "diviosr" Replace: Objects.requireNonNull(divisor, "divisor is null"); with

Re: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration)

Fine by me. Stephen On 11 December 2015 at 11:53, nadeesh tv wrote: > > Hi all, > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8032510/webrev.03/ > Regards, > Nadeesh TV > > > On 12/11/2015 4:45 PM, Stephen Colebourne wrote: >> >> Missing blank line

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

On 11/12/2015 09:24, Chris Hegarty wrote: : Nit: 687 * the specified stack size, and inherits initial values for Not sure if italic font of stack size is intentional since this constructor doesn't emphasize on this parameter. Right, replaced with: * the specified {@code stackSize}, and

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Hello Please review the new version on the patch. New webrev: Webrev hotspot: http://cr.openjdk.java.net/~kshefov/8141615/hotspot/webrev.02 Webrev jdk: http://cr.openjdk.java.net/~kshefov/8141615/jdk/webrev.02 What has been changed: 1. Added tests for the new added methods. 2. Removed CP tag

RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration)

Hi all, Please review a fix for Bug Id - https://bugs.openjdk.java.net/browse/JDK-8032510 Enhancement - Add java.time.Duration.dividedBy(Duration) webrev - http://cr.openjdk.java.net/~ntv/8032510/webrev.02/

Re: RFR:JDK-8032510 : Add java.time.Duration.dividedBy(Duration)

Missing blank line after the new method. Typo: "diviosr" Replace: Objects.requireNonNull(divisor, "divisor is null"); with Objects.requireNonNull(divisor, "divisor"); to match existing JSR-310 code. Test case looks fine. thanks Stephen On 11 December 2015 at 11:07, nadeesh tv

Re: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8

Hi Alex, I'm dropping jdk7u-dev mailing list for the moment. core-libs-dev is the mailing list where this review should happen. This fix would be required in JDK 9 first as per process. I think Sherman would be best to review if possible. Once it's soaked in JDK 9 for a few weeks, we could

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

On 11 Dec 2015, at 11:17, Alan Bateman wrote: > On 11/12/2015 09:24, Chris Hegarty wrote: >> : >>> Nit: >>> 687 * the specified stack size, and inherits initial values for >>> Not sure if italic font of stack size is intentional since this constructor >>> doesn't

Re: Is setting -Dsun.jnu.encoding from the command line supposed to work?

It seems like you haven't complained loud enough :) On Fri, Dec 11, 2015 at 6:00 PM, Martin Buchholz wrote: > IIRC I complained about sun.jnu.encoding "not working right" 10 years ago ... > > On Fri, Dec 11, 2015 at 8:53 AM, Volker Simonis >

RFR [9] Remove sun.misc.Request and RequestProcessor

sun.misc.Request and RequestProcessor are not used by the JDK, and I can find no usage outside the JDK either. I would like to propose their removal. $ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java $ hg rm src/java.base/share/classes/sun/misc/Request.java -Chris.

Re: Is setting -Dsun.jnu.encoding from the command line supposed to work?

IIRC I complained about sun.jnu.encoding "not working right" 10 years ago ... On Fri, Dec 11, 2015 at 8:53 AM, Volker Simonis wrote: > Hi, > > is setting -Dsun.jnu.encoding from the command line supposed to work > (i.e. if it should have any impact)? > > I'm just

Re: RFR [9] Remove sun.misc.Request and RequestProcessor

+1 I looked at those a while back and though to look for more; definitely dead wood. Roger On 12/11/2015 11:30 AM, Chris Hegarty wrote: sun.misc.Request and RequestProcessor are not used by the JDK, and I can find no usage outside the JDK either. I would like to propose their removal. $

Re: RFR [9] Remove sun.misc.Request and RequestProcessor

On 11 Dec 2015, at 17:01, Roger Riggs wrote: > +1 Thanks Roger. > I looked at those a while back and though to look for more; definitely dead > wood. There is some more dead wood, but these are logically connected and don’t touch any other areas. I’ll follow up on

Re: Reference.reachabilityFence

Sorry, one more point I forgot to mention: 3) what impact will this have, if any, on register allocation when a ref's lifetime is artificially extended without any "real" use. The thinking here is compiler should spill it and never reload, but it was unclear if it will do the right thing in its

Re: Reference.reachabilityFence

Hi Paul, No objections, but just wanted to summarize a couple of possible key performance issues that were raised on the concurrency-interest thread. You may have picked them up already, so pardon the repetition: 1) current impl/prototype is purposely barred from inlining - this will be a

Re: RFR [9] Remove sun.misc.Queue and replace usages with standard Collections

cc'ing awt-dev. This change looks okay. Mandy > On Dec 11, 2015, at 9:22 AM, Chris Hegarty wrote: > > More technical debt in sun.misc… > > Java SE has had support for Queues in Collections for many major releases, > sun.misc.Queue seems to predate that. I cannot

Re: RFR 8144675: Add a filtering collector

Hi Shinya, Thanks for updating the webrev. It looks fine. s'marks On 12/10/15 6:29 AM, ShinyaYoshida wrote: Hi Stuart, Thank you for your review and comment. The doc comment is wonderful! I like it, it must be helpful to users when they understand this method and how the filtering collector

Re: RFR [9] 8056152 API to create Threads that do not inherit InheritableThreadLocals

On 10 Dec 2015, at 19:59, Mandy Chung wrote: > On 12/10/2015 03:48 AM, Chris Hegarty wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~chegar/8056152/01/webrev/ > > Looks good. Thanks Mandy. > Nit: > 687 * the specified stack size, and inherits initial values

Re: Review request for JDK-8066982: ZonedDateTime.parse() returns wrong ZoneOffset around DST fall transition

Hi, Stephen, can you confirm that the added text and test in DateTimeFormatter is not a specification change? Our processes have a bit more to do if it is a spec change and it would limit the backport to JDK 8. This bug fix will cause an existing TCK/JCK test to fail but that is considered

Re: Is setting -Dsun.jnu.encoding from the command line supposed to work?

Don't do it, that's all I would suggest :-) same as "file.encoding", they are both supposed to be informative read-only system property. Here is the history of sun.jnu.encoding http://ccc.us.oracle.com/4958170 -sherman On 12/11/2015 09:00 AM, Martin Buchholz wrote: IIRC I complained about

RFR (JAXP): 8068839: newDuration(x) produces incorrect outputs for some values of x

This is a fix for an edge case. All tests passed after the fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8068839 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8068839/webrev/ Thanks, Joe

Re: Is setting -Dsun.jnu.encoding from the command line supposed to work?

On 12/11/2015 09:53 AM, Xueming Shen wrote: Don't do it, that's all I would suggest :-) same as "file.encoding", they are both supposed to be informative read-only system property. Here is the history of sun.jnu.encoding http://ccc.us.oracle.com/4958170 My apology, forgot the "ccc" is still

Re: RFR 8143404: Remove apple script engine code in jdk repository

Is there a work around? That really limits, actually kills a lot of functionality.

Re: RFR (JAXP): 8068839: newDuration(x) produces incorrect outputs for some values of x

Hi Joe, Looks fine. Roger On 12/11/2015 12:54 PM, huizhe wang wrote: This is a fix for an edge case. All tests passed after the fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8068839 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8068839/webrev/ Thanks, Joe

Re: RFR (JAXP): 8068839: newDuration(x) produces incorrect outputs for some values of x

Hi Joe, I think this looks OK. My only suggestion is I am not a fan of creating a one-off type of test vs integrating if at all possible a test such as this into existing test(s). The reason is it can get out of control the number of one off tests and makes it a bit harder to know the

RFR [9] Remove sun.misc.Queue and replace usages with standard Collections

More technical debt in sun.misc… Java SE has had support for Queues in Collections for many major releases, sun.misc.Queue seems to predate that. I cannot find any usages outside of the JDK, and just one in the JDK, AppletPanel. LinkedBlockingQueue appears to provide the necessary minimum

Re: RFR [7] 8133206: "java.lang.OutOfMemoryError: unable to create new native thread" caused by upgrade to zlib 1.2.8

Hi Sean, Thank you for your attention to this matter! Actually, the code review request was sent to core-libs-dev alias a month ago: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036463.html Unfortunately, we haven't got any feedback yet. Thanks, Nikolay On 11.12.2015

Re: RFR [9] Remove sun.misc.Request and RequestProcessor

On 12/11/2015 08:30 AM, Chris Hegarty wrote: sun.misc.Request and RequestProcessor are not used by the JDK, and I can find no usage outside the JDK either. I would like to propose their removal. $ hg rm src/java.base/share/classes/sun/misc/RequestProcessor.java $ hg rm

Re: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups (was: question on jdk_collections group in jdk/test/TEST.groups)

This is "fine", but jsr166 maintainers won't use it - we maintain our own list of tests to run. There's enough collection/concurrency overlap and too much testing ad-hoc-ery in existing jtreg tests. Eg. MOAT should be run for changes to any collection. If this is a test set you personally like,

Re: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups

I added Iterator and Comparator to "my" list of tests. Thanks! The key difference is that we don't try to separate concurrent and non-concurrent collections, so my "collections test set" includes all of /java/util/concurrent even though it's technically overkill. But we've optimized those tests

Re: RFR(s) 8145139 clean up jdk_collections and jdk_concurrent test groups

Hm, not really a ringing endorsement. On a second look, are the new test groups sufficiently close to the ones the JSR 166 maintainers would want to run? For example, your little 'find' script (cd ~/ws/jdk9/jdk/test && find java/util -type d \( \( -name concurrent -prune \) -o -name '*Set*'

Re: RFR [9] 8141615: Add new public methods to sun.reflect.ConstantPool

Hi Konstantin, the fix and tests look good to me, but I think you have to wait for OK from Coleen. One minor thing —it looks like there are no tests for other s.r.CP methods, could you please file an RFE against core-libs/j.l.reflect to cover them? Thanks, — Igor > On Dec 11, 2015, at 2:54