RFR 8166974: invokedynamic implementation should not wrap Errors

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8166974-indy-errors-not-wrapped-hotspot/webrev/ The JMV spec was recently updated to state the following in the Linkage Exceptions

Re: RFR 9: 8167166 : Java API docs mention a non-existent method getNanosOfSecond

+1 Naoto On 10/14/16 2:13 PM, Roger Riggs wrote: (With correct cr.openjdk.java.net link). Please review a corrected javadoc link correction in java.time.Instant. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-nano-8167166/ Thanks, Roger

Re: Process to add some default methods to javax.naming.Context?

On Fri, Oct 14, 2016 at 7:19 AM Vincent Ryan wrote: > The problem of having to cast the result of Context.lookup > > can > be solved using an existing method: >

Re: RFR 9: 8167166 : Java API docs mention a non-existent method getNanosOfSecond

(With correct cr.openjdk.java.net link). Please review a corrected javadoc link correction in java.time.Instant. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-nano-8167166/ Thanks, Roger

Re: Process to add some default methods to javax.naming.Context?

2016/10/13 13:39:44 -0700, brian.go...@oracle.com: > javax.naming is a JCP-controlled API. Adding to it would require a > maintenance release of whichever JSR covers JNDI (probably the Java EE > umbrella JSR.) You'll need to track down the spec lead and see if a MR > is in the works, and if

Re: RFR 9: 8167166 : Java API docs mention a non-existent method getNanosOfSecond

Looks good, Roger. Naoto On 10/14/16 2:03 PM, Roger Riggs wrote: Please review a corrected javadoc link correction in java.time.Instant. Webrev: http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-nano-8167166/ Thanks, Roger

RFR 9: 8167166 : Java API docs mention a non-existent method getNanosOfSecond

Please review a corrected javadoc link correction in java.time.Instant. Webrev: http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-nano-8167166/ Thanks, Roger

Re: RFR (JAXP) JDK-8167478 javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException: access denied ("java.io.FilePermission" "sko?ice")"

Looks fine. Paths.get is the way to go. -Joe On 10/14/16, 2:28 AM, Frank Yuan wrote: Hi Joe After some testing, I am sure current Windows platforms support Unicode although the default charset is Windows-1252. So now I check it by trying Paths.get method, which was also suggested by Max.

RE: Proposal for adding O_DIRECT support into JDK 9

Alan, Thank you for the feedback. We will come up with a more generic API that is flexible for supporting all the platforms that have DirectIO. Will send it here for review soon. Thanks, Lucy >-Original Message- >From: Alan Burlison [mailto:alan.burli...@oracle.com] >Sent: Friday,

Re: Process to add some default methods to javax.naming.Context?

Hello Laird, The problem of having to cast the result of Context.lookup can be solved using an existing method: InitialContext.doLookup

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

On 13/10/2016 18:30, Peter Levart wrote: Hi Paul, Alan, I incorporated Paul's suggestions into new webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.05/ This iteration also contains a nearly-exhaustive test of Class.getMethods(): PublicMethodsTest. It is

RE: RFR (JAXP) JDK-8167478 javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException: access denied ("java.io.FilePermission" "sko?ice")"

Hi Joe After some testing, I am sure current Windows platforms support Unicode although the default charset is Windows-1252. So now I check it by trying Paths.get method, which was also suggested by Max. Please check the new webrev http://cr.openjdk.java.net/~fyuan/8167478/webrev.01/ Thanks

Re: Proposal for adding O_DIRECT support into JDK 9

As has been pointed out already, platforms other than Linux provide similar functionality, yet this proposal does not provide any support for them. Even if such support isn't added initially, the APIs added for the Linux implementation should be generic enough that direct IO support could be

Re: Problem with multi-release jars, agents and the bootstrap class path

On 13/10/2016 21:43, Andrew Dinn wrote: : I am aware that the code I add to the bootstrap can only rely on a core subset of the JDK runtime classes being available. That ought not to be an issue -- I have deliberately kept the agent's footprint as small as possible because every time Byteman