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

Hello; I am new to this mailing list and its conventions; if I misstep I am happy to be pointed in the right direction. I was directed here by Mark Reinhold. Disclaimer in case it matters: I work for Oracle. I have long wanted there to be methods in javax.naming.Context like the following: //

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

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 actually a test generator. Given a Case

Request/discussion: BufferedReader reading using async API while providing sync API

Hi, I'm new here, so if this is belongs to a different mailing list please point me in the right direction. I looked at BufferedReader source code for java 9 long with the source code of the channels/streams used. I noticed that, like in java 7, BufferedReader does not use an Async API to load

RE: RFR: JEP draft for Linux/s3990x port

Hi Vladimir, I made a new webrev containing all outstanding changes merged into one patch http://cr.openjdk.java.net/~goetz/wr16/8166730-linuxs390-all/hotspot.wr01/ You probably saw my RFR with the s390 files. Best regards, Goetz. > -Original Message- > From: Vladimir Kozlov

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

Disclaimer: Although this post relates to handling of multi-release jars I'm cross-posting to jigsaw-dev as well as core-libs-dev. That's because the problem arises only because my JVMTI Java agent now needs to operate in dual mode to cope with Jigsaw when deployed on JDK9+ and to avoid reference

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

On 13/10/2016 17:40, Andrew Dinn wrote: : A Few Questions: Am I right that this is a deliberate choice of bootstrap loader behaviour? Or is there perhaps some other bug here? If this is a deliberate choice is there any possibility of reviewing it? Would it be particularly difficult to

RFR JDK-8167957: Remove FilePermission from default policy for jdk.charsets module

Hi Please help review the change for JDK-8167957 issue: https://bugs.openjdk.java.net/browse/JDK-8167957 webrev: http://cr.openjdk.java.net/~sherman/8167957/webrev There have been changes in jdk.charsets implementation to move pieces around for jigsaw. It appears the latest implementation

Re: RFR JDK-8167957: Remove FilePermission from default policy for jdk.charsets module

> On Oct 13, 2016, at 2:03 PM, Xueming Shen wrote: > > Hi > > Please help review the change for JDK-8167957 > > issue: https://bugs.openjdk.java.net/browse/JDK-8167957 > webrev: http://cr.openjdk.java.net/~sherman/8167957/webrev The change looks fine. Is there any

RE: Proposal for adding O_DIRECT support into JDK 9

O_DIRECT is widely adopted in applications designed for high IO throughput, such as webservers and Databases. It bypasses filesystem cache and Linux readahead buffer which some time slow down the throughput and cause unpredictable IO performance. As an example, we recently measured on our

Re: RFR JDK-8167957: Remove FilePermission from default policy for jdk.charsets module

Thumbs up as long as the tests well cover the cases. Mandy > On Oct 13, 2016, at 2:19 PM, Xueming Shen wrote: > > Yes, there are couple test cases in the cs unit/regression tests running > under security manager > when testing. > > sherman > > On 10/13/2016 02:13

Re: Proposal for adding O_DIRECT support into JDK 9

The question is, if support for fadvice() would be more flexible (and somewhat saner). And of course real async fio .) Gruss Bernd -- http://bernd.eckenfels.net Von: Alan Burlison Gesendet: Donnerstag, 13. Oktober 2016 14:30 An: Brian Burkhalter; Lu, Yingqi Cc: nio-...@openjdk.java.net;

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 Frank, Does this work as expected? The method doesn't seem to validate whether a character is legal as a file name. For example, on Windows, the original char (e.g. \u0159) used in the test is legal in a file name, but it didn't pass that decode/encode test by the Windows' default

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

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 you can convince them that this is a desirable addition.

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

On 13/10/16 18:27, Alan Bateman wrote: > What you see is deliberate. It wouldn't be impossible for the boot > loader to support MR JARs but it hardly seems worth the complexity. One > reason is that it's not a common way to deploy a general purpose > library. Even if it were then it would be

Re: RFR JDK-8167957: Remove FilePermission from default policy for jdk.charsets module

Yes, there are couple test cases in the cs unit/regression tests running under security manager when testing. sherman On 10/13/2016 02:13 PM, Mandy Chung wrote: On Oct 13, 2016, at 2:03 PM, Xueming Shen wrote: Hi Please help review the change for JDK-8167957

[9] RfR: 8165271: Fix use of reflection to gain access to private fields

JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8165271 Webrev: http://cr.openjdk.java.net/~ddehaven/8165271/jdk.0/ Synopsis: An upcoming change in the module system will prevent setAccessible calls from working across module boundaries. This patch allows the use of SharedSecrets instead

Re: [9] RfR: 8165271: Fix use of reflection to gain access to private fields

> On Oct 13, 2016, at 4:08 PM, David DeHaven wrote: > > > JBS Issue: > https://bugs.openjdk.java.net/browse/JDK-8165271 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/8165271/jdk.0/ This change looks fine. This hack should have been replaced long ago and happy

Re: Proposal for adding O_DIRECT support into JDK 9

An interesting comparison of approaches on a Linux server and an OS X client is given here: http://adityaramesh.com/io_benchmark/ Brian On Oct 13, 2016, at 3:09 PM, e...@zusammenkunft.net wrote: > The question is, if support for fadvice() would be more flexible (and > somewhat saner). > >

Re: RFR: JEP draft for Linux/s3990x port

Thank you, Goetz I submitted testing. Vladimir On 10/13/16 9:22 AM, Lindenmaier, Goetz wrote: Hi Vladimir, I made a new webrev containing all outstanding changes merged into one patch http://cr.openjdk.java.net/~goetz/wr16/8166730-linuxs390-all/hotspot.wr01/ You probably saw my RFR with the

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

Thank you, will change it. Frank > -Original Message- > From: Felix Yang [mailto:felix.y...@oracle.com] > Subject: Re: RFR (JAXP) JDK-8167478 > javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException: > access denied ("java.io.FilePermission"

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 Frank, I suggest you to use the following code snippet to make your code more readable. CharsetEncoder charsetEncoder = Charset.defaultCharset().newEncoder(); boolean b = charsetEncoder.canEncode(path);// alpha Any character in Unicode range would be valid as path if current

Re: RFR: JEP draft for Linux/s3990x port

Hi Vladimir, thanks for keeping us updated and hanks for setting the integrations date on the JEP. We think it is reasonable to do it before the JDK 10 forest will be forked as this will obviously save us a lot of work. The remaining shared changes are "8166561: [s390] Adaptions needed for s390

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

Hi all Would you like to review http://cr.openjdk.java.net/~fyuan/8167478/webrev.00/ ? Bug: https://bugs.openjdk.java.net/browse/JDK-8167478 This is a test bug, because Bug6341770.java is invalid when the system environment doesn't support non-ascii characters, the test will exit

RE: RFR: JEP draft for Linux/s3990x port

Hi Vladimir, I'm about to post the final change with the s390 files. All the others are reviewed. I'll then also send a complete webrev for testing. Best regards, Goetz > -Original Message- > From: Volker Simonis [mailto:volker.simo...@gmail.com] > Sent: Thursday, October 13, 2016

Request/discussion: BufferedReader reading using async API while providing sync API

Hi, I looked at BufferedReader source code for java 9 long with the source code of the channels/streams used. I noticed that, like in java 7, BufferedReader does not use an Async API to load data from files, instead, the data loading is all done synchronously even when the OS allows

Re: Proposal for adding O_DIRECT support into JDK 9

On 06/10/2016 00:31, Brian Burkhalter wrote: Given that the functionality of O_DIRECT on Linux appears to be supported by other interfaces on OS X, Solaris, and Windows, I wonder whether the patch will need to be refactored in some way to accommodate these other operating systems? For reference

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

+1 Stephen On 12 October 2016 at 19:16, Anubhav Meena wrote: > Hi Roger, > > Thanks for the suggestion, have made the suggested changes and shifted the > tests to /java/time/test/java/time/chrono/TestUmmAlQuraChronology.java. > > Updated webrev: >

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

A comment on naming, alpha to ALPHA ? -Felix > 在 2016年10月13日，17:05，Frank Yuan 写道： > > Hi all > > > > Would you like to review http://cr.openjdk.java.net/~fyuan/8167478/webrev.00/ > ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167478 > > > > This is a test

Re: RFR:JDK-8163330:HijrahDate aligned day of week incorrect

Thanks Roger, appreciate that. > On Oct 13, 2016, at 3:09 AM, Roger Riggs wrote: > > Hi, > > Looks ok. > > Typically, there is a space after the '//' comment characters, it makes it > easier to read. > Also, in this case, I don't think the comments help. "Monday"