Re: JDK 10 RFR of JDK-8183512: Remove intermittent key from nio test Transfer4GBFile.java TransferTo6GBFile.java and StressLoopback.java

On 04/07/2017 03:13, Amy Lu wrote: java/nio/channels/FileChannel/Transfer4GBFile.java java/nio/channels/FileChannel/TransferTo6GBFile.java java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Tests were failing intermittently and the related bugs (JDK-8176895, JDK-8177550 and JDK-817

Re: JDK 10 RFR of JDK-8183512: Remove intermittent key from nio test Transfer4GBFile.java TransferTo6GBFile.java and StressLoopback.java

Including core-libs-dev On 7/4/17 10:13 AM, Amy Lu wrote: java/nio/channels/FileChannel/Transfer4GBFile.java java/nio/channels/FileChannel/TransferTo6GBFile.java java/nio/channels/AsynchronousSocketChannel/StressLoopback.java Tests were failing intermittently and the related bugs (JDK-8176895,

Re: Enhancements to the java.lang.StringCoding class

As Martin pointed out, the UTF-16 variants probably are not critical enough to have "special" fastpath implementation in StringCoding. If better performance of these UTF-16 charsets is really desired, it might be worth implementing the sun.nio.ArrayDe/Encoder interface in UnicodeDe/Encoder to

Re: Zip Extended Timestamp signedness changed in JDK9 but not JDK8

On 03/07/2017 20:05, Simon Spero wrote: : It is strange that this wasn't backported to jdk8u, since other changes to zip rom around the same time are present. Also, this fix doesn't seem to be mentioned in JIRA or the release notes. There were API changes as part of this update so not appro

Re: Is there any reason why the MacOS X port doesn't provide a UserDefinedFileAttributeView?

On 03/07/2017 20:39, Simon Spero wrote: It seems like it ought be relatively simple to add, since the API is not too far off of Linux (with NO_FOLLOW as an option to syscall rather than a separate entry point). This has been discussed on nio-dev once or twice. It wasn't in the original port

Is there any reason why the MacOS X port doesn't provide a UserDefinedFileAttributeView?

It seems like it ought be relatively simple to add, since the API is not too far off of Linux (with NO_FOLLOW as an option to syscall rather than a separate entry point). Also, will trees for 9.x be split repositories, or will the consolidator work his magic?

Re: [10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X

+1 On 6/28/17, 3:13 PM, Naoto Sato wrote: Thanks, Brent! Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8160199/webrev.04/ And my comments embedded below: On 6/28/17 2:16 PM, Brent Christian wrote: Hi, Naoto This looks quite good. I will test a bit with some of the trickier

Zip Extended Timestamp signedness changed in JDK9 but not JDK8

Tracking down the cause of a JDK 9 test failure for Apache Commons Compress under JDK 9 has revealed a change in JDK 9's handling of ZIP extended timestamps compared to JDK8. The issue is caused by a change in the way that extended timestamps are converted into FileTimes. Previously, the value wa

RE: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi Christoph, Thank you very much for your help! For JDK9 updates and JDK8 updates, it is desirable if we can back port the removal of volatile. What should I do for it? Regards, Ogata From: "Langer, Christoph" To: Kazunori Ogata , "nio-...@openjdk.java.net" Cc: core-libs-dev

RE: 8182743: Ineffective use of volatile hurts performance of Charset.atBugLevel()

Hi, I've pushed to JDK10 now: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7a2bc0a80087 What do you think, shall we try to downport a fix to JDK9 updates and JDK8 updates, which simply removes the volatile as we can't bring this behavior changing fix down? Thanks Christoph > -Original