Hi Alan, thaks for looking at the javadoc/CSR.
On Mon, Jan 7, 2019 at 8:10 PM Alan Bateman <alan.bate...@oracle.com> wrote: > > On 07/01/2019 11:13, Langer, Christoph wrote: > > Hi, > > > > I’ve amended the jdk.zipfs module documentation in > src/jdk.zipfs/share/classes/module-info.java to document the new behavior > (e.g. support of PosixFileAttributeView) as requested by Alan. I’ve also > updated the CSR. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.4/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8213082 > > > I think this is on the right path now. I'll start with the javadoc as that > will take a few iterations and you'll need to get that agreed before > finalizing the CSR. > > The proposed update starts out "Path objects residing in a zip file system > ..." isn't quite right. I think you want start with something like "File > systems created by the zip file system provider support the POSIX file > attributes defined by the {@link PosixFileAttributeView}". > > I think the main issue that will need to be worked out is how the bulk read > PosixFileAttributeView::readAttributes behaves when the zip entry doesn't > have the external file attributes. UOE isn't right because UOE should be > thrown or not thrown based on concrete/implementation type. One option is to > throw IOE, another is to have it return a PosixFileAttributes that contains > an empty permission set. We considered this, but it is problematic because it is perfectly valid to have a file with external file attributes where none of the Posix attributes is actually set (i.e. an empty set of Posix files attributes). This wouldn't be distinguishable from the case where a file has no external file attributes. So it seems we have to resort to throwing an IOE? > The latter has the advantage that you can pass the object to anything that > excepts a BasicFileAttributes. Having set/getOwner throw UOE is okay. Once we > have agreement on how the bulk read behaves then it should be easy to agree > the javadoc change. > > -Alan.
