Hi All, Please find the most recent version of the patch available at http://cr.openjdk.java.net/~igraves/8164900-2/
In this version, we have following two changes: 1. Move O_DIRECT flag from StandardOpenOption to ExtendedOpenOption 2. Move the checks of O_DIRECT from native code to Java code. Please let us know your feedback. Thanks, Lucy -----Original Message----- From: nio-dev [mailto:nio-dev-boun...@openjdk.java.net] On Behalf Of Lu, Yingqi Sent: Tuesday, September 27, 2016 9:57 AM To: Alan Bateman <alan.bate...@oracle.com>; core-libs-dev@openjdk.java.net Cc: nio-...@openjdk.java.net Subject: RE: Proposal for adding O_DIRECT support into JDK 9 Alan, Thank you for the explanation, we will modify the code accordingly and send it out soon for review. Thanks, Lucy -----Original Message----- From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Tuesday, September 27, 2016 8:45 AM To: Lu, Yingqi <yingqi...@intel.com>; core-libs-dev@openjdk.java.net Cc: nio-...@openjdk.java.net Subject: Re: Proposal for adding O_DIRECT support into JDK 9 On 26/09/2016 19:50, Lu, Yingqi wrote: > Alan, you mean readv0/write0 or read0/write0? I just want to make sure > :-) Apologies, I meant each of the native methods where the decision to use direct I/O or not would be a lot more maintainable in Java. You'll see that there are already code paths for direct vs. heap buffers. > > Anyone else has other opinions on where is the best home for O_DIRECT flag? > The flags under jdk.unsupported will eventually be removed in the future JDK > release? > > If we agree ExtendedOpenOpen is the best home for O_DIRECT, we can modify > that for sure. > I think ExtendedOpenOption is the right place. It's still TDB as to whether to put these extensions but that should be transparent to anyone using this when on the class path. -Alan