Re: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k'

Hi Roger, I have fixed the same error in DateTimeFormatterBuiler. Please see the updated webrev below. Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.01/ Thanks Abhijit On 12/16/2016 8:01 PM, Roger Riggs wrote: Hi, Sorry, I meant DateTimeFormatterBuilder. Roger On

Re: JDK 9 RFR of JDK-8171824: Remove OpenNonIntegralNumberOfSampleframes.java and ServerIdentityTest.java from ProblemList

Hi Amy, Looks fine to remove those. Roger On 12/20/16 10:50 PM, Amy Lu wrote: Please review the patch for taking back two tests. javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java This test was removed from ProblemList in JDK-8170581, but was wrongly added back to

JDK 9 RFR of JDK-8171824: Remove OpenNonIntegralNumberOfSampleframes.java and ServerIdentityTest.java from ProblemList

Please review the patch for taking back two tests. javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java This test was removed from ProblemList in JDK-8170581, but was wrongly added back to ProblemList by a merge: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/16233

Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

> On Dec 19, 2016, at 1:41 AM, Peter Levart wrote: > > Hi, > > This is the latest webrev of changes to Class.getMethod() and > Class.getMethods(), rebased to current tip of jdk9-dev, incorporating > comments from CCC review: > >

Re: RFR of JDK-8029360: java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently

Hi Daniel, Thank you for reviewing, modified as you suggested and pushed the code. -Hamlin On 2016/12/20 18:35, Daniel Fuchs wrote: Hi Hamlin, DGCDeadLock.java: 61 public static boolean finished = false; 62 static DGCDeadLock test = new DGCDeadLock(); 63 static int

Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

> On 20 Dec 2016, at 00:56, Peter Levart wrote: > > Hi Paul, > > On 12/20/2016 02:51 AM, Paul Sandoz wrote: >> Hi Peter, >> >> Very good work (that’s one heck of a test on steroids). > > Which would not be possible without such nice APIs like Stream with lambdas >

Re: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

Hi Nadeesh, On 12/20/2016 2:34 PM, nadeesh tv wrote: Hi Roger & Stephen , Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8145633/webrev.12/ Changes included : 1. Doc changes and cosmetic changes suggested by Roger (except the note about delay..)

Re: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

Hi Roger & Stephen , Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8145633/webrev.12/ Changes included : 1. Doc changes and cosmetic changes suggested by Roger (except the note about delay..) 2. Changed the behavior of 'e' to parse only 1 digit

Re: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

In the test provider_adjacentValuePatterns2(), please add {"wwe", Y, w, c, "20161201", 2016, 12, 1}, This should succeed, because a single number is all that is needed to parse day-of-week. (So, it will need to be removed from the invalid patterns test). Line 1869 will need to change to

Re: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

Hi Max, Comments: - Is there a better term/phrase to use other than "foo"; it does not appear elsewhere in the @implNote. The use of "cpath" and "npath" implies that someone is reading the source code. The description of the behavior of the implementation should use the same

Re: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

Hi Nadeesh, A nice bit of work. DateTimeFormatterBuilder: 4774: A note about the design to delay the choice of TemporalField and creating PrinterParser until the locale is known would be useful 4789: Please add the @param descriptions so the purpose of the new arguments is

Re: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64

> For the failing case, the first time it calls checkNames, the "ans" (the 3rd > arg) is "current working dir" (/path/scratch/1). Is it possible to use ./tmp as "ans"? --Max

Re: RFR of JDK-8029360: java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently

Hi Hamlin, DGCDeadLock.java: 61 public static boolean finished = false; 62 static DGCDeadLock test = new DGCDeadLock(); 63 static int registryPort = -1; 1. 'finished' and 'registryPort' should be volatile since they are written and read by multiple threads. 2. 'test'

RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns

Hi all, BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 Issue: Support adjacent value parsing for Localized Patterns Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ Pattern 'c' and 'W' were previously allowed to have 'zero padding' which was not explicitly mentioned in

Re: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

Looks fine Aleksej. Approved for jdk8u-dev. regards, Sean. On 19/12/2016 15:53, Aleks Efimov wrote: Hi, Can I, please, ask JDK8 reviewer to look through the backported changes? Thanks, Aleksej On 15/12/16 17:06, Aleks Efimov wrote: Hi, Can I, please, have an approval to backport

Re: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64

Thank you Paul for reviewing this. The failure is from testcase checkDrivePaths, in which it calls General.checkNames -> checkSlashes -> checkSlash -> checkNames public static void checkNames(int depth, boolean create, String ans, String ask)

Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

Hi Paul, On 12/20/2016 02:51 AM, Paul Sandoz wrote: Hi Peter, Very good work (that’s one heck of a test on steroids). Which would not be possible without such nice APIs like Stream with lambdas and JavaCompiler... ;-) Trivially on Class you could turn the “ Note that there may be …”