Hi Alan, thaks for looking at the javadoc/CSR. On Mon, Jan 7, 2019 at 8:10 PM Alan Bateman <Alan.Bateman@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.