Proposal for adding O_DIRECT support into JDK 9
yingqi.lu at intel.com
Sun Aug 28 16:11:19 UTC 2016
Thank you both for the suggestions. I agree it would be cleaner to make O_DIRECT an extended open options within nio package.
We will modify the patch and update the community soon!
From: Uwe Schindler [mailto:uschindler at apache.org]
Sent: Sunday, August 28, 2016 3:30 AM
To: 'Andrew Haley' <aph at redhat.com>; Lu, Yingqi <yingqi.lu at intel.com>; core-libs-dev at openjdk.java.net
Cc: Kaczmarek, Eric <eric.kaczmarek at intel.com>
Subject: RE: Proposal for adding O_DIRECT support into JDK 9
IMHO, I'd stay with FOS/FIS/RAF completely out of this business and not change them anymore. Those are legacy APIs!
I'd suggest to add this to StandardOpenOptions (https://docs.oracle.com/javase/8/docs/api/java/nio/file/StandardOpenOption.html) and use it solely with the Java 7+ NIO.2 Path APIs. No need to change the old-style java.io.File based APIs. This is easy to implement and add, because you would only add the new Enum constant and then implement it in the default FileSystem(-Provider) for each platform.
uschindler at apache.org
ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/
> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of Andrew Haley
> Sent: Sunday, August 28, 2016 12:23 PM
> To: Lu, Yingqi <yingqi.lu at intel.com>; core-libs-dev at openjdk.java.net
> Cc: Kaczmarek, Eric <eric.kaczmarek at intel.com>
> Subject: Re: Proposal for adding O_DIRECT support into JDK 9
> On 26/08/16 23:31, Lu, Yingqi wrote:
> > The proposal adds 4 API methods to java/io/FileInputStream.java,
> > java/io/OutputStream.java to enable the feature. In addition, it add
> > O_DIRECT with two more modes "ro" (read-only and direct) and "rwo"
> > (read-write and direct) to java/io/RandomAccessFile.java.
> > public FileInputStream(String name, boolean direct) throws
> Adding a boolean for O_DIRECT does not scale well. There are many
> other flags, and if there is some future expansion it would mean
> adding more boolean arguments to the call signature. It might be
> worth considering a more direct way to make the call to open(2). I
> appreciate that not every flag passed to open() makes sense, though.
> And there is Windows etc. to think about. But something like
> new FileInputStream(filename, File.DIRECT | File.APPEND)
> is much more scalable and involves less argument marshalling.
More information about the core-libs-dev