Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

> On 15 Jun 2016, at 19:33, Mark Sheppard wrote: > > Hi, > please oblige and review the updated webrev: > > http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/ I’m happy with the code changes here. Trivially, an alternative stylistic option for the method declaration: private st

Re: JDK 9 RFR of JDK-8071859: AnnotationInvocationHandler.equals(Object) return true when apply to annotation

> On Jun 15, 2016, at 4:21 PM, Joseph D. Darcy wrote: > > Hello, > > Please review the changes to address > >JDK-8071859: AnnotationInvocationHandler.equals(Object) return true when > apply to annotation >http://cr.openjdk.java.net/~darcy/8071859.0/ +1 Mandy

Re: JDK 9 RFR of JDK-8071859: AnnotationInvocationHandler.equals(Object) return true when apply to annotation

On 16 Jun 2016, at 00:21, Joseph D. Darcy wrote: > > Hello, > > Please review the changes to address > >JDK-8071859: AnnotationInvocationHandler.equals(Object) return true when > apply to annotation >http://cr.openjdk.java.net/~darcy/8071859.0/ This looks good to me Joe. -Chris.

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

thanks Roger ... I'll attend to them regards Mark On 15/06/2016 21:57, Roger Riggs wrote: Hi Mark, Thanks for the test cleanup. In the new security policy files, is it important to enumerate the individual permissions instead of using AllPermission? If it is significant, the perhaps a comm

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

Steve, In JarFile, please use methods not fields to return the new information. The information in question is not constant across versions. Using methods instead of fields avoid over-committing on a particular implementation, etc. Cheers, -Joe On 6/15/2016 3:49 PM, Steve Drach wrote: I’v

JDK 9 RFR of JDK-8071859: AnnotationInvocationHandler.equals(Object) return true when apply to annotation

Hello, Please review the changes to address JDK-8071859: AnnotationInvocationHandler.equals(Object) return true when apply to annotation http://cr.openjdk.java.net/~darcy/8071859.0/ Thanks, -Joe

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

I’ve updated the webrev to address the issue of the constructor accepting values like Version.parse(“7.1”) http://cr.openjdk.java.net/~sdrach/8150680/webrev.01/ > On Jun 15, 2016, at 8:56 AM, Steve Drach wrote: > >>> Please review the fo

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

fyi Mark, The problem running the new test was a bad build on my end, sorry for the noise. Roger On 6/15/2016 4:57 PM, Roger Riggs wrote: Hi Mark, Thanks for the test cleanup. In the new security policy files, is it important to enumerate the individual permissions instead of using AllPe

Review Request: JDK-8159524 jdeps -jdkinternals throws NPE when no replacement is known

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8159524/webrev.00/index.html Simple fix in jdeps -jdkinternals to handle properly when no replacement is known. Mandy

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Hi Mark, Thanks for the test cleanup. In the new security policy files, is it important to enumerate the individual permissions instead of using AllPermission? If it is significant, the perhaps a comment is in order, otherwise, there will be doubt about why the long list instead of the simpler

Re: RFR 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

> On Jun 13, 2016, at 1:58 PM, Brent Christian > wrote: > > Hi, > > Please review this Mac-only fix: > > http://cr.openjdk.java.net/~bchristi/7131356/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-7131356 > > Thanks go to Gerard Ziemski for the thorough investigation and detailed > w

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

Hi Steve, On 06/15/2016 05:56 PM, Steve Drach wrote: >Fields or methods is another discussion point for the base and runtime versions. My thinking is, in this case fields and methods are equivalent, the method not giving any more flexibility than a field. For example the method JarFile.bas

Re: RFR: 8065831: Ensure the pack200/unpack200 help is consistent with man page

> On Jun 15, 2016, at 11:34 AM, Kumar Srinivasan > wrote: > > > Oops, I missed making changes to the unpack200 executable's > help strings, no changes to DriverResource.java. > > http://cr.openjdk.java.net/~ksrini/8065831/webrev.02/ +1 Mandy

Re: Review request: JDK-8068764 java/lang/ClassLoader/ExtDirs.java failed with Exception java.lang.IllegalThreadStateException: process hasn't exited

On 15/06/2016 19:17, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8068764/webrev.00/ The ExtDirs and EndorsedDirs tests might fail due to the insufficient wait time on fastdebug build on a slow machine. This patch converts the tests to use the test library ProcessTools

Re: RFR: 8065831: Ensure the pack200/unpack200 help is consistent with man page

Oops, I missed making changes to the unpack200 executable's help strings, no changes to DriverResource.java. http://cr.openjdk.java.net/~ksrini/8065831/webrev.02/ Just finished verifying with jprt. Thanks Kumar On Jun 14, 2016, at 6:31 PM, Kumar Srinivasan wrote: Thanks for looking at thi

Re: RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Hi, please oblige and review the updated webrev: http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/ http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev.01/ based on the feedback, the following amendments were made: the scope of the tests reduced the removal of the export f

Review request: JDK-8068764 java/lang/ClassLoader/ExtDirs.java failed with Exception java.lang.IllegalThreadStateException: process hasn't exited

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8068764/webrev.00/ The ExtDirs and EndorsedDirs tests might fail due to the insufficient wait time on fastdebug build on a slow machine. This patch converts the tests to use the test library ProcessTools that will wait for the child process to fin

Re: [9] RFR: 8043387: java/time/test/java/util/TestFormatter.java failed.

Looks fine, Roger On 6/10/2016 5:52 PM, Naoto Sato wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8043387 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8043387/webrev.00/ The issue only is reproducible when the underly

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

>> Please review the following changeset: >> >> webrev: http://cr.openjdk.java.net/~sdrach/8150680/webrev.00/index.html >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8150680 >>

Re: [9] RFR: 8043387: java/time/test/java/util/TestFormatter.java failed.

+1 On 6/10/16 2:52 PM, Naoto Sato wrote: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8043387 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8043387/webrev.00/ The issue only is reproducible when the underlying OS's default ti

Re: RFR: 8150680 JarFile.Release enum needs reconsideration with respect to it's values

On 15/06/2016 00:17, Steve Drach wrote: Hi, Please review the following changeset: webrev: http://cr.openjdk.java.net/~sdrach/8150680/webrev.00/index.html issue: https://bugs.openjdk.java.net/browse/JDK-8150680

RFR: 8159590: Remove deprecated methods from jdk.internal.misc.VM

Hi, after VM.java was encapsulated and moved from sun.misc to jdk.internal.misc, the rationale for keeping a number of deprecated methods and constants no longer applies and these methods should be removed: Webrev: http://cr.openjdk.java.net/~redestad/8159590/webrev.01/ Bug: https://bugs.open

Re: Create java.util.stream.Stream from Iterator / Enumeration

Almost: - you can use Enumeration.asIterator() rather than creating your own. Right, for JDK 9 that will the right way. In the meantime under JDK 8 I will have to write my own ;-) - I don’t think you can assume the Iterator has an encounter order (even though there is a form of order related