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

On 13/06/2016 16:20, Brent Christian wrote: Hi, Naoto. Thank you for having a look. On 13/06/2016 14:43, Naoto Sato wrote: On 6/13/16 1:58 PM, Brent Christian wrote: The original Apple code then calls into "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into "language_REGION"

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

Hi, Naoto. Thank you for having a look. On 13/06/2016 14:43, Naoto Sato wrote: On 6/13/16 1:58 PM, Brent Christian wrote: The original Apple code then calls into "JRSCopyCanonicalLanguageForPrimaryLanguage" to map "language" into "language_REGION" (ex. "en"-->"en_US", "fr"-->"fr_FR", etc.), t

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

Hi Steve, > On Jun 13, 2016, at 11:02 AM, Steve Drach wrote: > > Hi, > > 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 9 7131356 : (props) "No Java runtime present, requesting install" when creating VM from JNI [macosx]

Hi Brent, On 6/13/16 1:58 PM, Brent Christian wrote: Apple suggested changing the JDK initialization order so any access to JRS happens only after the JLI_MemAlloc symbol is available. We believe a better solution is to re-implement the JSR APIs in question, as a move toward eventually droppin

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

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 write-up in the bug report. The symptoms: On those OS X machines where the de

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

I agree JSObject.getWindow(Applet) should have forRemoval=true, as I raised in awt-dev thread. The confusion there was when the API marked forRemoval=true in JDK 9 and when it should really be removed. Mandy > On Jun 13, 2016, at 12:53 PM, Philip Race wrote: > > Alan, > > See the comment h

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

Alan, See the comment here : http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011478.html Probably you should chime in directly on that discussion with such input .. -phil. On 6/13/16, 12:47 PM, Alan Bateman wrote: On 13/06/2016 20:26, Philip Race wrote: PS .. also you probably sh

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

On 13/06/2016 20:26, Philip Race wrote: PS .. also you probably should just suppress lint on the jdk.jsobject module The change you propose to JSObject is going to cause a potential conflict with the ongoing review discussion about this here :- http://mail.openjdk.java.net/pipermail/awt-dev

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

PS .. also you probably should just suppress lint on the jdk.jsobject module The change you propose to JSObject is going to cause a potential conflict with the ongoing review discussion about this here :- http://mail.openjdk.java.net/pipermail/awt-dev/2016-June/011472.html -phil. On 6/13/16,

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

Hmm .. given that the majority of the jdk changes are in client - specifically swing & accessibility - including the swing mailing list would have increased the likelihood of the right people clicking on this webrev link. IMO, we should remove these unusable fields from the Swing API - where

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

Hi, 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

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

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/ issue: https://bugs.openj

Re: RFR: JDK-8031043 ClassValue's backing map should have a smaller initial size

Hi, I explored various strategies to minimize worst-case lookup performance for MethodType keys in LinearProbeHashtable. One idea is from the "Hopscotch hashing" algorithm [1] which tries to optimize placement of keys by moving them around at each insertion or deletion. While a concurrent Hop

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

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 change. throws InstantiationException, IllegalAccessException, InvocationTargetException The patch sent to the list (http://mail.

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

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: http://cr.openjdk.java.net/~jlahoda/8153362/lang

RFR 9: 8155808: Process.getInputStream().skip() method is faulty

A latent issue with Process InputStreams support for the skip method was reported[1]. Though the InputStream returned is a BufferedInputStream, in some cases, the skip method calls FileInputStream.seek on the pipe containing output from the process but the pipes do not support seek. The propose

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

Hi, That example kind of glosses over the need to handle 3 new exceptions. That's been my annoyance with this change. throws InstantiationException, IllegalAccessException, InvocationTargetException Roger On 6/12/2016 11:43 PM, joe darcy wrote: On 6/12/2016 7:21 PM, Wang Weijun wrote: W

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

Gentle reminder! Forwarded Message Subject: RFR[9] 8039955: jdk/lambda/LambdaTranslationTest1 - java.lang.AssertionError: Date: Tue, 7 Jun 2016 14:58:47 +0530 From: shilpi.rast...@oracle.com To: core-libs-dev Hi All, Please review fix for https://bugs.openjdk.j

Re: RFR 8139507: WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs

Hi Alan, On 12.6.2016 20:51, Alan Bateman wrote: On 10/06/2016 17:05, Jan Lahoda wrote: The other Preferences implementations used this pattern, so I used it as well. I don't have a problem with using double-checked locking. Updated webrev: http://cr.openjdk.java.net/~jlahoda/8139507/webrev.