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

> On Jun 14, 2016, at 6:31 PM, Kumar Srinivasan > wrote: > > Thanks for looking at this. I wrapped all of them. > > http://cr.openjdk.java.net/~ksrini/8065831/webrev.01/ > > Looks fine. Disclaimer - I didn’t validate with the current implementation :) Mandy

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

Thanks for looking at this. I wrapped all of them. http://cr.openjdk.java.net/~ksrini/8065831/webrev.01/ Kumar On Jun 14, 2016, at 1:19 PM, Kumar Srinivasan wrote: Hi, Please review the simple changes which makes pack200 help consistent with man page.

RE: A new helper method Arrays.asArray

The same issue is present even without any varargs or generics present, when using plain old arrays: String[] list1 = new String[1]; list1[0] = "hello"; Integer[] list2 = new Integer[1]; list2[0] = 1; String[][]

Re: Chair voting to *accept* (rather than approve) 8159111: JShell API: Add access to wrappers and dependencies

On 6/14/2016 5:44 PM, Joseph D. Darcy wrote:

Chair voting to approve 8159111: JShell API: Add access to wrappers and dependencies

Re: A new helper method Arrays.asArray

- Mail original - > De: "timo kinnunen" > À: "Remi Forax" > Cc: "core-libs-dev" , "Louis Wasserman" > > Envoyé: Mardi 14 Juin 2016 23:39:19 > Objet: RE: A new helper method Arrays.asArray

RE: A new helper method Arrays.asArray

I think @SafeVarargs should be OK here since the array containing the varargs already exists before the method starts executing and so the annotation amounts to asserting that the passed-in vararg-array is just as safe during the execution of the method as it is after the method execution

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

> On Jun 14, 2016, at 1:19 PM, Kumar Srinivasan > wrote: > > Hi, > > Please review the simple changes which makes pack200 > help consistent with man page. > http://cr.openjdk.java.net/~ksrini/8065831/webrev.00/ Can you wrap the long lines? Mandy

Re: RFR JDK-8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException

Hi Sherman, The fix looks good. It would be helpful if the test for 8072582 generated the string instead of using a literal that's more than 1K long. The exact length is significant because Scanner's default buffer size is 1024, so the delimiter has to straddle the buffer boundary. The

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

Hi, Please review the simple changes which makes pack200 help consistent with man page. http://cr.openjdk.java.net/~ksrini/8065831/webrev.00/ Thanks Kumar

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

Hi Paul, I see the point, that making it too easy there. I might have to some little explain where I have started from. I wanted to go over all resource URL's from a ClassLoader and read them as a Stream: Enumeration resources = myInstance.getClassLoader().getResources("resource.name");

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

hi Brent, Thank you very much for tackling this. The code overall looks good (aside from the 3 code language sub tag case that we need to handle, as Naoto pointed out) Here are my 2 small comments: #1 63 CFRelease(languages); // was missing from original patch I think we can

Re: A new helper method Arrays.asArray

Hi Timo, your implementation can not use @SafeVarargs because you leak the array (you return it) so you're code is not safe because you can not be sure that the resulting array will not be modified after the call to asArray. Louis, because you can not create an array of parametrized type in

Re: RFR: 8153652 Update javap to be multi-release jar aware

On 14/06/2016 18:16, Steve Drach wrote: Please review the following changeset that simply supplies the help information for the already existing javap command line option, -multi-release. webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/

A new helper method Arrays.asArray

Hi, I have found that many times I need to write this simple helper method: public static @SafeVarargs T[] asArray(T… ts) { return ts; } I usually need this when I have several implementations I’m comparing and I want to change the code for observing one of them to observing two or

Re: RFR: 8153652 Update javap to be multi-release jar aware

>> Please review the following changeset that simply supplies the help >> information for the already existing javap command line option, >> -multi-release. >> >> webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/ >> >> issue:

Re: RFR: 8153652 Update javap to be multi-release jar aware

On 13/06/2016 18:24, Steve Drach wrote: Hi, Please review the following changeset that simply supplies the help information for the already existing javap command line option, -multi-release. webrev: http://cr.openjdk.java.net/~sdrach/8153652/webrev.00/

Re: RFR: 81536534 Update jdeps to be multi-release jar aware

> On Jun 14, 2016, at 9:41 AM, Steve Drach wrote: > > Hi Mandy, > >>> Please review the following changeset to make jdeps multi-release jar aware. >>> >>> webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html >>>

Re: RFR: 81536534 Update jdeps to be multi-release jar aware

Hi Mandy, >> Please review the following changeset to make jdeps multi-release jar aware. >> >> webrev: http://cr.openjdk.java.net/~sdrach/8153654/webrev.00/index.html >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8153654

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

On 6/13/16 4:20 PM, Brent Christian wrote: On 13/06/2016 14:43, Naoto Sato wrote: Also, the array index "2" to assume the language length is 2 is not correct, as there are three letter language codes. So the code should literally look for "-" instead. Great, thanks. I will fix that. FYI,

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

Hi Patrick, Enumeration now has an asIterator method, that’s our attempt to bridge the old traversal world to the less old ( :-) ) world. Bridging the gap between the less old world and the new world (streams) is more subtle, and we have been holding out on that. We wanted to avoid providing

RE: RFR: 8153955: java.util.logging.FileHandler can not create file synchronously over 101 access

Hi all, May I request one more review for this bug fix.? Thank you very much Daniel for your review. Regards, Ramanand. -Original Message- From: Daniel Fuchs Sent: Friday, June 10, 2016 7:47 PM To: Ramanand Patil; Bernd Eckenfels; core-libs-dev@openjdk.java.net Subject: Re: RFR:

Re: RFR: 8153652 Update javap to be multi-release jar aware

> On 13 Jun 2016, at 10:24, Steve Drach wrote: > > Hi, > > Please review the following changeset that simply supplies the help > information for the already existing javap command line option, > -multi-release. > > webrev:

Re: RFR[9] 8039955: jdk/lambda/LambdaTranslationTest1 - java.lang.AssertionError:

> On 13 Jun 2016, at 03:44, shilpi.rast...@oracle.com wrote: > > Gentle reminder! > > > Forwarded Message > Subject: RFR[9] 8039955: jdk/lambda/LambdaTranslationTest1 - > java.lang.AssertionError: > Date: Tue, 7 Jun 2016 14:58:47 +0530 > From:

Re: JDK 9 RFR of JDK-8159330: Improve deprecation text for Class.newInstance

Hi Joe, With the full method context, the proposed text is sufficient. Thanks, Roger On 6/13/2016 12:37 PM, joe darcy wrote: Hi Roger, On 6/13/2016 6:59 AM, Roger Riggs wrote: Hi, That example kind of glosses over the need to handle 3 new exceptions. That's been my annoyance with this

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

Hi Alan, On 14.6.2016 12:57, Alan Bateman wrote: On 13/06/2016 17:12, Jan Lahoda wrote: Hello, There is: https://bugs.openjdk.java.net/browse/JDK-8153362 which is about a new warning that should be produced by javac when exported API refers to types not exported/accessible to the API

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

Hi Phil, Thanks for the comments. I was preferring @SuppressWarnings over -Xlint:-unexportedinapi because it allows to disable the check only on selected elements (as opposed to disabling it for a whole module, where a newly added API might inadvertently still cause a new warning); and also

Re: JDK-8153362: [jigsaw] Add javac -Xlint warning to list exposed types which are not accessible

On 13/06/2016 17:12, Jan Lahoda wrote: Hello, There is: https://bugs.openjdk.java.net/browse/JDK-8153362 which is about a new warning that should be produced by javac when exported API refers to types not exported/accessible to the API clients. I've put my current javac change here:

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

Hi there, I know you are busy getting the latest release ready. Still I have question according the java.util.stream.Stream's static helper methods. During my work I ran into a couple places where creating a Stream out of a Iterator or Enumeration directly would be quite handy. At the