From alanb at openjdk.java.net Mon Mar 1 13:00:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 1 Mar 2021 13:00:41 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v2] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> Message-ID: On Wed, 17 Feb 2021 10:09:59 GMT, Sebastian Stenzel wrote: >> Deduplicated code in these classes: >> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`. >> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions. >> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()` >> >> For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587) >> >> This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72). >> >> I plan to add further commits to clean up this code, once the deduplication is reviewed. > > Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: > > Restored indentation from former LinuxUserDefinedFileAttributeView and LinuxNativeDispatcher Overall I think this looks good, just a few minor nits with the method descriptions on protected methods (they don't actually need to be protected of course). src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 49: > 47: > 48: // returns the maximum supported length of xattr names (in bytes, including namespace) > 49: protected abstract int maxNameLength(); I think we should move this declaration to after the constructor to avoid having an abstract method declared in the middle of private API elements. I'd probably use /** .. */ style for the method description as it's not private. src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java line 177: > 175: // returns true if extended attributes enabled on file system where given > 176: // file resides, returns false if disabled or unable to determine. > 177: protected boolean isExtendedAttributesEnabled(UnixPath path) { This used to be private method in LinuxFileStore, now it's a protected method so might be cleaner to change the method description to use /** .. */ comment as it's used from sub-classes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From github.com+1204330+overheadhunter at openjdk.java.net Mon Mar 1 13:45:42 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Mon, 1 Mar 2021 13:45:42 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v2] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> Message-ID: On Mon, 1 Mar 2021 12:54:34 GMT, Alan Bateman wrote: >> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: >> >> Restored indentation from former LinuxUserDefinedFileAttributeView and LinuxNativeDispatcher > > src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 49: > >> 47: >> 48: // returns the maximum supported length of xattr names (in bytes, including namespace) >> 49: protected abstract int maxNameLength(); > > I think we should move this declaration to after the constructor to avoid having an abstract method declared in the middle of private API elements. I'd probably use /** .. */ style for the method description as it's not private. Will change the comment style. Regarding method order: I agree. However, this class needs refactoring due to code duplication and complex branching anyway, as I have proposed in my original PR. I can sure move this single method, but then it will still be "field, field, method, method, field, field, constructor, method, ..." Having this in mind, can you confirm this should be done in _this_ PR or don't you think it'd fit into the follow-up cleanup better? ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From alanb at openjdk.java.net Mon Mar 1 18:21:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 1 Mar 2021 18:21:39 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v2] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> Message-ID: On Mon, 1 Mar 2021 13:42:29 GMT, Sebastian Stenzel wrote: >> src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 49: >> >>> 47: >>> 48: // returns the maximum supported length of xattr names (in bytes, including namespace) >>> 49: protected abstract int maxNameLength(); >> >> I think we should move this declaration to after the constructor to avoid having an abstract method declared in the middle of private API elements. I'd probably use /** .. */ style for the method description as it's not private. > > Will change the comment style. > > Regarding method order: I agree. However, this class needs refactoring due to code duplication and complex branching anyway, as I have proposed in my original PR. I can sure move this single method, but then it will still be "field, field, method, method, field, field, constructor, method, ..." > > Having this in mind, can you confirm this should be done in _this_ PR or don't you think it'd fit into the follow-up cleanup better? If it's okay with you, then I'd prefer to do it in this PR. So let's get this PR out of the way and then discuss the refactoring in a follow-on PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From github.com+1204330+overheadhunter at openjdk.java.net Tue Mar 2 05:40:05 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Tue, 2 Mar 2021 05:40:05 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> Message-ID: <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> > Deduplicated code in these classes: > - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`. > - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions. > - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()` > > For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587) > > This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72). > > I plan to add further commits to clean up this code, once the deduplication is reviewed. Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: Moved method below constructor and changed comment style ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2604/files - new: https://git.openjdk.java.net/jdk/pull/2604/files/79b623c2..639a82a3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2604&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2604&range=01-02 Stats: 14 lines in 2 files changed: 9 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2604.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2604/head:pull/2604 PR: https://git.openjdk.java.net/jdk/pull/2604 From github.com+1204330+overheadhunter at openjdk.java.net Tue Mar 2 05:40:05 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Tue, 2 Mar 2021 05:40:05 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v2] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> Message-ID: On Mon, 1 Mar 2021 12:58:19 GMT, Alan Bateman wrote: >> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: >> >> Restored indentation from former LinuxUserDefinedFileAttributeView and LinuxNativeDispatcher > > Overall I think this looks good, just a few minor nits with the method descriptions on protected methods (they don't actually need to be protected of course). Applied discussed changes. @AlanBateman can you sponsor this? ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From alanb at openjdk.java.net Tue Mar 2 12:51:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 2 Mar 2021 12:51:43 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> Message-ID: <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> On Tue, 2 Mar 2021 05:40:05 GMT, Sebastian Stenzel wrote: >> Deduplicated code in these classes: >> - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`. >> - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions. >> - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()` >> >> For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587) >> >> This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72). >> >> I plan to add further commits to clean up this code, once the deduplication is reviewed. > > Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: > > Moved method below constructor and changed comment style Thanks for the update. A minor nit is that the new javadoc for isExtendedAttributesEnabled means there is 100+ line in the source file, mildly annoying when reviewing diffs in side-by-side view. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2604 From github.com+1204330+overheadhunter at openjdk.java.net Tue Mar 2 13:19:44 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Tue, 2 Mar 2021 13:19:44 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> Message-ID: On Tue, 2 Mar 2021 12:48:32 GMT, Alan Bateman wrote: > A minor nit is that the new javadoc for isExtendedAttributesEnabled means there is 100+ line in the source file, mildly annoying when reviewing diffs in side-by-side view. Just out of curiosity, since I only see the diff in GitHub or via my local git client: Are these webrev things somehow related to the review process and mess this up? In an earlier comment, brian suggested that individual commits in git are somehow "squashed" by webrev, causing all the review pain in the original PR in the first place. I know this is off-topic, but I just want to understand what things I need to be aware of, if I contribute further patches. I have the feeling that Skara wasn't so much about transitioning to git and GitHub but rather added a bridge between those and some internal tooling. ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From azeller at openjdk.java.net Tue Mar 2 13:34:59 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Tue, 2 Mar 2021 13:34:59 GMT Subject: RFR: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 Message-ID: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 ------------- Commit messages: - Fix ext3 detection in LinuxFileStore Changes: https://git.openjdk.java.net/jdk/pull/2778/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2778&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262844 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2778.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2778/head:pull/2778 PR: https://git.openjdk.java.net/jdk/pull/2778 From alanb at openjdk.java.net Tue Mar 2 14:37:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 2 Mar 2021 14:37:40 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> Message-ID: On Tue, 2 Mar 2021 13:17:15 GMT, Sebastian Stenzel wrote: > Just out of curiosity, since I only see the diff in GitHub or via my local git client: Are these webrev things somehow related to the review process and mess this up? In an earlier comment, brian suggested that individual commits in git are somehow "squashed" by webrev, causing all the review pain in the original PR in the first place. > > I know this is off-topic, but I just want to understand what things I need to be aware of, if I contribute further patches. I have the feeling that Skara wasn't so much about transitioning to git and GitHub but rather added a bridge between those and some internal tooling. Some people look at the diffs in on github where it's possible to customize the view. Some people look use the generated webrev. There's a bot that generates the webrev and adds a link to the PR, look for the comment from "mlbridge" ("mailing list bridge"). ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From github.com+1204330+overheadhunter at openjdk.java.net Tue Mar 2 14:44:56 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Tue, 2 Mar 2021 14:44:56 GMT Subject: Integrated: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView In-Reply-To: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> Message-ID: On Wed, 17 Feb 2021 08:41:43 GMT, Sebastian Stenzel wrote: > Deduplicated code in these classes: > - `LinuxUserDefinedAttributeView` + `BsdUserDefinedAttributeView` ? `UnixUserDefinedAttributeView`. Due to different supported length of attribute names, I added an abstract method `UnixUserDefinedAttributeView.maxNameLength()`. > - `LinuxNativeDispatcher` + `BsdNativeDispatcher` ? `UnixNativeDispatcher`. I basically just moved the Linux implementation up to Unix and added preprocessor directives to distinguish Linux/BSD/Other. Others will throw ENOTSUP UnixExceptions. > - `LinuxFileStore.isExtendedAttributesEnabled()` + `BsdFileStore.isExtendedAttributesEnabled()` ? `UnixFileStore.isExtendedAttributesEnabled()` > > For the latter I introduced `UnixConstants.XATTR_NOT_FOUND`, which is `ENODATA` on Linux and `ENOATTR` on BSD. Note that `UnixConstants.ENODATA` is still present, as @AlanBateman "would prefer if we left ENODATA so that it can be used in Linux specific code" (Quote from https://github.com/openjdk/jdk/pull/2363#issuecomment-772534587) > > This also fixes `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)` on macOS/BSD. Previosly an [invocation was missing](https://github.com/openjdk/jdk/blob/jdk-17%2B7/src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java#L70-L72). > > I plan to add further commits to clean up this code, once the deduplication is reviewed. This pull request has now been integrated. Changeset: 0de6abd4 Author: Sebastian Stenzel Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/0de6abd4 Stats: 1159 lines in 16 files changed: 171 ins; 968 del; 20 mod 8260966: (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView 8260691: (fs) LinuxNativeDispatcher should link to xattr functions Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From sebastian.stenzel at gmail.com Tue Mar 2 15:13:59 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 2 Mar 2021 16:13:59 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes Message-ID: Following up on JDK-8260966, I'd like to propose two further (independent) changes: 1. Fail fast in UnixFileStore.isExtendedAttributesEnabled(UnixPath path) [1], if UnixNativeDispatcher.c is incapable of handling xattr, thus avoid unnecessary I/O. 2. Refactor UnixUserDefinedFileAttributeView.java with these goals: - deduplicate code - reduce branching and improve readability - fix leaking NativeBuffer by applying try-with-resource where applicable - fix UnsupportedOperationException if trying to read to a Buffer that doesn't provide a backing array I'd need someones assistance to create a bunch of issues for these tasks. I can provide an issue description on this mailing list, but I don't have access to the issue tracker. Cheers! Sebastian [1]: https://github.com/openjdk/jdk/blob/0de6abd4b49e7111effbaef99a93317bcd7246f0/src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java#L181 From Alan.Bateman at oracle.com Tue Mar 2 15:22:54 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Mar 2021 15:22:54 +0000 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: References: Message-ID: <713db86a-1fa0-0f42-082d-5c9fc7f2a244@oracle.com> On 02/03/2021 15:13, Sebastian Stenzel wrote: > - fix leaking NativeBuffer by applying try-with-resource where applicable > - fix UnsupportedOperationException if trying to read to a Buffer that doesn't provide a backing array > I can create bugs but I think it would be useful to know if this the above are real issues or not. All usages of NativeBuffer should already be using try-finally blocks (try-with-resources will improve this of course), have you found cases here this isn't the case? The read method handle both direct and heap buffers, which cases are you running into where the backing memory is something else? -Alan. From sebastian.stenzel at gmail.com Tue Mar 2 15:29:48 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Tue, 2 Mar 2021 16:29:48 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: <713db86a-1fa0-0f42-082d-5c9fc7f2a244@oracle.com> References: <713db86a-1fa0-0f42-082d-5c9fc7f2a244@oracle.com> Message-ID: > On 2. Mar 2021, at 16:22, Alan Bateman wrote: > > On 02/03/2021 15:13, Sebastian Stenzel wrote: >> - fix leaking NativeBuffer by applying try-with-resource where applicable >> - fix UnsupportedOperationException if trying to read to a Buffer that doesn't provide a backing array >> > I can create bugs but I think it would be useful to know if this the above are real issues or not. All usages of NativeBuffer should already be using try-finally blocks (try-with-resources will improve this of course), have you found cases here this isn't the case? The read method handle both direct and heap buffers, which cases are you running into where the backing memory is something else? > > -Alan. So far, I just found one case: https://github.com/openjdk/jdk/blob/0de6abd4b49e7111effbaef99a93317bcd7246f0/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L230-L258 Variable `nb` declared in line 230, assigned in 237, leaks in 258. There may be further cases, but this is speculative. Anyway a try-with-resource refactoring should increase robustness. From alanb at openjdk.java.net Tue Mar 2 19:53:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 2 Mar 2021 19:53:49 GMT Subject: RFR: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 10:00:43 GMT, Arno Zeller wrote: > 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 @bplb Would you have cycles to look at this one? We've always tried to reduce the probing on the mount points but this one means we will probe ext3 systems. I can't quire tell if this is something specific to SuSE or whether other distributions enable it too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From bpb at openjdk.java.net Tue Mar 2 23:38:42 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 2 Mar 2021 23:38:42 GMT Subject: RFR: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: References: Message-ID: <812qIf_aik1xc-ETE8wnsq5Y-QNfHnM3mcuFzjuWI7Y=.aebeb5df-5bc4-40a8-a06f-32c076768fd2@github.com> On Tue, 2 Mar 2021 19:51:18 GMT, Alan Bateman wrote: >> 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 > > @bplb Would you have cycles to look at this one? We've always tried to reduce the probing on the mount points but this one means we will probe ext3 systems. I can't quire tell if this is something specific to SuSE or whether other distributions enable it too. Apparently as of version 11-SP3, the default file system of SLES was changed to Ext3 [1]. In [2] it is stated that "The default inode size of ext3 file systems has been increased from 128 bytes to 256 bytes on SLES11, because of extended attributes / ACLs." >From this it may be inferred that extended attributes are enabled by default from SLES 11. One may therefore suppose that the kernel was built with configuration item CONFIG_EXT3_FS_XATTR set to Y [3]. [1] https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP3/, section 6.8 [2] https://www.suse.com/support/kb/doc/?id=000017683 [3] https://cateee.net/lkddb/web-lkddb/EXT3_FS_XATTR.html ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From bpb at openjdk.java.net Wed Mar 3 01:15:55 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Mar 2021 01:15:55 GMT Subject: RFR: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: <812qIf_aik1xc-ETE8wnsq5Y-QNfHnM3mcuFzjuWI7Y=.aebeb5df-5bc4-40a8-a06f-32c076768fd2@github.com> References: <812qIf_aik1xc-ETE8wnsq5Y-QNfHnM3mcuFzjuWI7Y=.aebeb5df-5bc4-40a8-a06f-32c076768fd2@github.com> Message-ID: On Tue, 2 Mar 2021 23:36:03 GMT, Brian Burkhalter wrote: >> @bplb Would you have cycles to look at this one? We've always tried to reduce the probing on the mount points but this one means we will probe ext3 systems. I can't quire tell if this is something specific to SuSE or whether other distributions enable it too. > > Apparently as of version 11-SP3, the default file system of SLES was changed to Ext3 [1]. In [2] it is stated that > > "The default inode size of ext3 file systems has been increased from 128 bytes to 256 bytes on SLES11, because of extended attributes / ACLs." > > From this it may be inferred that extended attributes are enabled by default from SLES 11. One may therefore suppose that the kernel was built with configuration item CONFIG_EXT3_FS_XATTR set to Y [3]. > > [1] https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP3/, section 6.8 > [2] https://www.suse.com/support/kb/doc/?id=000017683 > [3] https://cateee.net/lkddb/web-lkddb/EXT3_FS_XATTR.html Based on testing it looks like xattr is enabled by default for ext3 file systems in Ubuntu 18.04 LTS (Linux kernel 4.15.0). ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From bpb at openjdk.java.net Wed Mar 3 02:16:46 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Mar 2021 02:16:46 GMT Subject: RFR: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: References: <812qIf_aik1xc-ETE8wnsq5Y-QNfHnM3mcuFzjuWI7Y=.aebeb5df-5bc4-40a8-a06f-32c076768fd2@github.com> Message-ID: On Wed, 3 Mar 2021 01:13:12 GMT, Brian Burkhalter wrote: >> Apparently as of version 11-SP3, the default file system of SLES was changed to Ext3 [1]. In [2] it is stated that >> >> "The default inode size of ext3 file systems has been increased from 128 bytes to 256 bytes on SLES11, because of extended attributes / ACLs." >> >> From this it may be inferred that extended attributes are enabled by default from SLES 11. One may therefore suppose that the kernel was built with configuration item CONFIG_EXT3_FS_XATTR set to Y [3]. >> >> [1] https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP3/, section 6.8 >> [2] https://www.suse.com/support/kb/doc/?id=000017683 >> [3] https://cateee.net/lkddb/web-lkddb/EXT3_FS_XATTR.html > > Based on testing it looks like xattr is enabled by default for ext3 file systems in Ubuntu 18.04 LTS (Linux kernel 4.15.0). >From [1]: Some filesystems, such as Reiserfs (and, historically, ext2 and ext3), require the filesystem to be mounted with the user_xattr mount option in order for user extended attributes to be used. In the current ext2, ext3, and ext4 filesystem implementations, the total bytes used by the names and values of all of a file's extended attributes must fit in a single filesystem block .... which reads as if extended attributes are now always supported in ext2, ext3, and ext4. [1] https://man7.org/linux/man-pages/man7/xattr.7.html ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From stuefe at openjdk.java.net Wed Mar 3 06:53:39 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 3 Mar 2021 06:53:39 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> Message-ID: <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> On Tue, 2 Mar 2021 14:35:12 GMT, Alan Bateman wrote: >>> A minor nit is that the new javadoc for isExtendedAttributesEnabled means there is 100+ line in the source file, mildly annoying when reviewing diffs in side-by-side view. >> >> Just out of curiosity, since I only see the diff in GitHub or via my local git client: Are these webrev things somehow related to the review process and mess this up? In an earlier comment, brian suggested that individual commits in git are somehow "squashed" by webrev, causing all the review pain in the original PR in the first place. >> >> I know this is off-topic, but I just want to understand what things I need to be aware of, if I contribute further patches. I have the feeling that Skara wasn't so much about transitioning to git and GitHub but rather added a bridge between those and some internal tooling. > >> Just out of curiosity, since I only see the diff in GitHub or via my local git client: Are these webrev things somehow related to the review process and mess this up? In an earlier comment, brian suggested that individual commits in git are somehow "squashed" by webrev, causing all the review pain in the original PR in the first place. >> >> I know this is off-topic, but I just want to understand what things I need to be aware of, if I contribute further patches. I have the feeling that Skara wasn't so much about transitioning to git and GitHub but rather added a bridge between those and some internal tooling. > > Some people look at the diffs in on github where it's possible to customize the view. Some people look use the generated webrev. There's a bot that generates the webrev and adds a link to the PR, look for the comment from "mlbridge" ("mailing list bridge"). Unfortunately this broke AIX and I don't know if this would work on BSD (not sure if anyone still maintains those). https://bugs.openjdk.java.net/browse/JDK-8262926 ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From sebastian.stenzel at gmail.com Wed Mar 3 07:16:05 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 3 Mar 2021 08:16:05 +0100 Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> Message-ID: <206F4BFE-22E7-4465-B292-3AE9B856AC14@gmail.com> > On 3. Mar 2021, at 07:53, Thomas Stuefe wrote: > > Unfortunately this broke AIX and I don't know if this would work on BSD (not sure if anyone still maintains those). > > https://bugs.openjdk.java.net/browse/JDK-8262926 Oh sh... Well, since this is merely an access modifier, it is easy to fix. While I could easily do this, I'd be flying blind here, since I can't test on AIX. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.java.net Wed Mar 3 07:23:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 3 Mar 2021 07:23:51 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> Message-ID: On Wed, 3 Mar 2021 06:51:27 GMT, Thomas Stuefe wrote: >>> Just out of curiosity, since I only see the diff in GitHub or via my local git client: Are these webrev things somehow related to the review process and mess this up? In an earlier comment, brian suggested that individual commits in git are somehow "squashed" by webrev, causing all the review pain in the original PR in the first place. >>> >>> I know this is off-topic, but I just want to understand what things I need to be aware of, if I contribute further patches. I have the feeling that Skara wasn't so much about transitioning to git and GitHub but rather added a bridge between those and some internal tooling. >> >> Some people look at the diffs in on github where it's possible to customize the view. Some people look use the generated webrev. There's a bot that generates the webrev and adds a link to the PR, look for the comment from "mlbridge" ("mailing list bridge"). > > Unfortunately this broke AIX and I don't know if this would work on BSD (not sure if anyone still maintains those). > > https://bugs.openjdk.java.net/browse/JDK-8262926 If you do a PR, I can test it for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From stuefe at openjdk.java.net Wed Mar 3 07:29:40 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 3 Mar 2021 07:29:40 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> Message-ID: On Wed, 3 Mar 2021 07:19:42 GMT, Thomas Stuefe wrote: >> Unfortunately this broke AIX and I don't know if this would work on BSD (not sure if anyone still maintains those). >> >> https://bugs.openjdk.java.net/browse/JDK-8262926 > > If you do a PR, I can test it for you. (you could leave it as draft PR to avoid spamming the mailing lists) ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From Alan.Bateman at oracle.com Wed Mar 3 07:31:29 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Mar 2021 07:31:29 +0000 Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> Message-ID: On 03/03/2021 06:53, Thomas Stuefe wrote: > : > Unfortunately this broke AIX and I don't know if this would work on BSD (not sure if anyone still maintains those). > > https://bugs.openjdk.java.net/browse/JDK-8262926 > The BSD port is in maintained downstream rather than in OpenJDK and no requirement that it builds on BSD before integrating changes here. It's somewhat historical that there are Bsd* classes here, it dates from initial macOS port and Apple contributions in 7u4. We aren't required to do any building or testing on AIX prior to integrating changes. Instead, we've always left it to SAP or IBM to keep that port alive. So apologies, there will be periodic breakage and needs someone with easy access to AIX systems to keep it working. -Alan From sebastian.stenzel at gmail.com Wed Mar 3 07:33:28 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 3 Mar 2021 08:33:28 +0100 Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> Message-ID: > On 3. Mar 2021, at 08:23, Thomas Stuefe wrote: > > On Wed, 3 Mar 2021 06:51:27 GMT, Thomas Stuefe > wrote: > >>>> Just out of curiosity, since I only see the diff in GitHub or via my local git client: Are these webrev things somehow related to the review process and mess this up? In an earlier comment, brian suggested that individual commits in git are somehow "squashed" by webrev, causing all the review pain in the original PR in the first place. >>>> >>>> I know this is off-topic, but I just want to understand what things I need to be aware of, if I contribute further patches. I have the feeling that Skara wasn't so much about transitioning to git and GitHub but rather added a bridge between those and some internal tooling. >>> >>> Some people look at the diffs in on github where it's possible to customize the view. Some people look use the generated webrev. There's a bot that generates the webrev and adds a link to the PR, look for the comment from "mlbridge" ("mailing list bridge"). >> >> Unfortunately this broke AIX and I don't know if this would work on BSD (not sure if anyone still maintains those). >> >> https://bugs.openjdk.java.net/browse/JDK-8262926 > > If you do a PR, I can test it for you. Here you go: https://github.com/openjdk/jdk/pull/2805 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Wed Mar 3 07:41:38 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 3 Mar 2021 08:41:38 +0100 Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> Message-ID: Hi Alan, On Wed, Mar 3, 2021 at 8:31 AM Alan Bateman wrote: > On 03/03/2021 06:53, Thomas Stuefe wrote: > > : > > Unfortunately this broke AIX and I don't know if this would work on BSD > (not sure if anyone still maintains those). > > > > https://bugs.openjdk.java.net/browse/JDK-8262926 > > > The BSD port is in maintained downstream rather than in OpenJDK and no > requirement that it builds on BSD before integrating changes here. It's > somewhat historical that there are Bsd* classes here, it dates from > initial macOS port and Apple contributions in 7u4. > > We aren't required to do any building or testing on AIX prior to > integrating changes. Instead, we've always left it to SAP or IBM to keep > that port alive. So apologies, there will be periodic breakage and needs > someone with easy access to AIX systems to keep it working. > > No problem, we are aware of that and usually fix without much noise. Also, Oracle developers are usually very careful to at least "dry-fix" AIX or at least ping us, for which we are thankful. On the whole this works quite well. In this case I was afraid, due to the PR title, that this fix would involve major implementation work on our side. Since it looked like Sebastian unified a lot of code for Linux and MacOs without being aware that there are other supported Unices. From his initial response I take that this is an easy fix though. As for BSD, the hotspot os sources in particular contain code which seems like it could have bitrotted for the non-mac-platforms. I always suspected that these configurations are seldom built. But that is a different issue of course. Thanks, Thomas > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuefe at openjdk.java.net Wed Mar 3 09:51:53 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 3 Mar 2021 09:51:53 GMT Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> Message-ID: On Wed, 3 Mar 2021 07:26:51 GMT, Thomas Stuefe wrote: >> If you do a PR, I can test it for you. > > (you could leave it as draft PR to avoid spamming the mailing lists) @ArnoZeller will take care of the AIX build issue. Thanks, Sebastian, for the quick response. ------------- PR: https://git.openjdk.java.net/jdk/pull/2604 From sebastian.stenzel at gmail.com Wed Mar 3 09:55:16 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 3 Mar 2021 10:55:16 +0100 Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> Message-ID: <430335E8-0E04-4586-B3ED-3F55DC061147@gmail.com> > On 3. Mar 2021, at 10:51, Thomas Stuefe wrote: > > On Wed, 3 Mar 2021 07:26:51 GMT, Thomas Stuefe wrote: > >>> If you do a PR, I can test it for you. >> >> (you could leave it as draft PR to avoid spamming the mailing lists) > > @ArnoZeller will take care of the AIX build issue. Thanks, Sebastian, for the quick response. Maybe you didn't see my previous mail, but I created a PR already: https://github.com/openjdk/jdk/pull/2805 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arno.zeller at sap.com Wed Mar 3 10:11:29 2021 From: arno.zeller at sap.com (Zeller, Arno) Date: Wed, 3 Mar 2021 10:11:29 +0000 Subject: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] In-Reply-To: <430335E8-0E04-4586-B3ED-3F55DC061147@gmail.com> References: <7T4W2_lS-6a_5V38DHWoMCY5Lx2IaeqPqWbk9_Xw3Hk=.a291069d-be04-4816-8df5-2de5cc436faa@github.com> <6WZjT3bjLHKhgVpCJ9yemCYfJ_un-o6DL4ccUfWWCdg=.e0507a1d-5f57-4741-97b4-7fcb6eb8ed2c@github.com> <0mtR4Sd-fM1KsfkFRNqIq8UggDPc5R55NooRsM6PNcg=.73777005-d149-4e7c-8b18-bce859bea6c1@github.com> <5-qD55OTjM5-KXMNAA917kKIn2v5zkgZDIHYj0YUBSA=.c4d0a4d4-1df0-4fba-84a6-da3bbe73c3be@github.com> <430335E8-0E04-4586-B3ED-3F55DC061147@gmail.com> Message-ID: Hi Sebastian, your PR looks good and fixes the issue. I had a similar change open but not created a pull request till now. I tested it in our build environment and it works. Best regards, Arno PS: I am not a (R)eviewer. From: nio-dev On Behalf Of Sebastian Stenzel Sent: Mittwoch, 3. M?rz 2021 10:55 To: Thomas Stuefe Cc: nio-dev at openjdk.java.net Subject: Re: RFR: JDK-8260966 (fs) Consolidate Linux and macOS implementations of UserDefinedFileAttributeView [v3] On 3. Mar 2021, at 10:51, Thomas Stuefe > wrote: On Wed, 3 Mar 2021 07:26:51 GMT, Thomas Stuefe > wrote: If you do a PR, I can test it for you. (you could leave it as draft PR to avoid spamming the mailing lists) @ArnoZeller will take care of the AIX build issue. Thanks, Sebastian, for the quick response. Maybe you didn't see my previous mail, but I created a PR already: https://github.com/openjdk/jdk/pull/2805 -------------- next part -------------- An HTML attachment was scrubbed... URL: From azeller at openjdk.java.net Wed Mar 3 11:10:39 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Wed, 3 Mar 2021 11:10:39 GMT Subject: RFR: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: References: <812qIf_aik1xc-ETE8wnsq5Y-QNfHnM3mcuFzjuWI7Y=.aebeb5df-5bc4-40a8-a06f-32c076768fd2@github.com> Message-ID: <5Wyu_CG-ryr-YXuuRYt5xRdq0q5Lb6miWcPXjVM7yCI=.5df23349-841f-4406-945d-8e0b269f8463@github.com> On Wed, 3 Mar 2021 02:14:17 GMT, Brian Burkhalter wrote: >> Based on testing it looks like xattr is enabled by default for ext2 and ext3 file systems in Ubuntu 18.04 LTS (Linux kernel 4.15.0). > > From [1]: > > Some filesystems, such as Reiserfs (and, historically, ext2 and > ext3), require the filesystem to be mounted with the user_xattr > mount option in order for user extended attributes to be used. > > In the current ext2, ext3, and ext4 filesystem implementations, > the total bytes used by the names and values of all of a file's > extended attributes must fit in a single filesystem block .... > > which reads as if extended attributes are now always supported in ext2, ext3, and ext4. > > [1] https://man7.org/linux/man-pages/man7/xattr.7.html I can add that RHEL 8.3 also has extended attributes as default mount option for ext3 and will not show up in /proc/mounts. To me it seems that the default was changed some time ago, but it might not be so easy to find a kernel version that enabled it by default as it was in case of ext4. And even if we could find a kernel version that started to use it as default, it might still be possible to disable it during build time or by setting default mount options on the ext3 filesystem with tune2fs. These will also not show up in /proc/mounts (just checked on RHEL 8.3): # tune2fs -l /dev/sdb1 | grep "Default mount" Default mount options: **user_xattr** acl # cat /proc/mounts | grep /dev/sdb1 And this is the same for ext4. I think the only save way to determine the support is to check on the filesystem. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From Alan.Bateman at oracle.com Wed Mar 3 11:34:13 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Mar 2021 11:34:13 +0000 Subject: RFR: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: <5Wyu_CG-ryr-YXuuRYt5xRdq0q5Lb6miWcPXjVM7yCI=.5df23349-841f-4406-945d-8e0b269f8463@github.com> References: <812qIf_aik1xc-ETE8wnsq5Y-QNfHnM3mcuFzjuWI7Y=.aebeb5df-5bc4-40a8-a06f-32c076768fd2@github.com> <5Wyu_CG-ryr-YXuuRYt5xRdq0q5Lb6miWcPXjVM7yCI=.5df23349-841f-4406-945d-8e0b269f8463@github.com> Message-ID: <356c97f3-fd08-50d8-4ad6-46b0d6178359@oracle.com> On 03/03/2021 11:10, Arno Zeller wrote: > : > I can add that RHEL 8.3 also has extended attributes as default mount option for ext3 and will not show up in /proc/mounts. > > To me it seems that the default was changed some time ago, but it might not be so easy to find a kernel version that enabled it by default as it was in case of ext4. Okay, it seems there is enough evidence now that extended attributes are enabled on ext3 on several distributions so I think we'll have to proceed with this. -Alan. From clanger at openjdk.java.net Wed Mar 3 11:34:46 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 3 Mar 2021 11:34:46 GMT Subject: RFR: 8262844: FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: <5Wyu_CG-ryr-YXuuRYt5xRdq0q5Lb6miWcPXjVM7yCI=.5df23349-841f-4406-945d-8e0b269f8463@github.com> References: <812qIf_aik1xc-ETE8wnsq5Y-QNfHnM3mcuFzjuWI7Y=.aebeb5df-5bc4-40a8-a06f-32c076768fd2@github.com> <5Wyu_CG-ryr-YXuuRYt5xRdq0q5Lb6miWcPXjVM7yCI=.5df23349-841f-4406-945d-8e0b269f8463@github.com> Message-ID: On Wed, 3 Mar 2021 11:07:36 GMT, Arno Zeller wrote: >> From [1]: >> >> Some filesystems, such as Reiserfs (and, historically, ext2 and >> ext3), require the filesystem to be mounted with the user_xattr >> mount option in order for user extended attributes to be used. >> >> In the current ext2, ext3, and ext4 filesystem implementations, >> the total bytes used by the names and values of all of a file's >> extended attributes must fit in a single filesystem block .... >> >> which reads as if extended attributes are now always supported in ext2, ext3, and ext4. >> >> [1] https://man7.org/linux/man-pages/man7/xattr.7.html > > I can add that RHEL 8.3 also has extended attributes as default mount option for ext3 and will not show up in /proc/mounts. > > To me it seems that the default was changed some time ago, but it might not be so easy to find a kernel version that enabled it by default as it was in case of ext4. > > And even if we could find a kernel version that started to use it as default, it might still be possible to disable it during build time or by setting default mount options on the ext3 filesystem with tune2fs. These will also not show up in /proc/mounts (just checked on RHEL 8.3): > >> #tune2fs -l /dev/sdb1 | grep "Default mount" > Default mount options: **user_xattr** acl > #cat /proc/mounts | grep /dev/sdb1 > > > And this is the same for ext4. > > I think the only save way to determine the support is to check on the filesystem. What do you think? I also think that if we were to do it right, we should go with always probing. @ArnoZeller, can you try that out in our test landscape? Alternatively, if there's a reason against always probing, maybe we could add an option to enable probing? ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From github.com+1204330+overheadhunter at openjdk.java.net Wed Mar 3 12:23:13 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Wed, 3 Mar 2021 12:23:13 GMT Subject: Integrated: JDK-8262926 JDK-8260966 broke AIX build Message-ID: Fixed access modifier of `isExtendedAttributesEnabled` which has been moved to super class. ------------- Commit messages: - fixed wrong access modifier Changes: https://git.openjdk.java.net/jdk/pull/2805/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2805&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262926 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2805.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2805/head:pull/2805 PR: https://git.openjdk.java.net/jdk/pull/2805 From stuefe at openjdk.java.net Wed Mar 3 12:23:13 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 3 Mar 2021 12:23:13 GMT Subject: Integrated: JDK-8262926 JDK-8260966 broke AIX build In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 07:31:35 GMT, Sebastian Stenzel wrote: > Fixed access modifier of `isExtendedAttributesEnabled` which has been moved to super class. Looks good to me, and Arno tested it. Thanks for the quick response! I think this falls under the trivial rule, which means you can integrate it right away without having to wait 24hrs. Thanks, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2805 From clanger at openjdk.java.net Wed Mar 3 12:23:13 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 3 Mar 2021 12:23:13 GMT Subject: Integrated: JDK-8262926 JDK-8260966 broke AIX build In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 07:31:35 GMT, Sebastian Stenzel wrote: > Fixed access modifier of `isExtendedAttributesEnabled` which has been moved to super class. Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2805 From github.com+1204330+overheadhunter at openjdk.java.net Wed Mar 3 12:23:13 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Wed, 3 Mar 2021 12:23:13 GMT Subject: Integrated: JDK-8262926 JDK-8260966 broke AIX build In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 11:14:15 GMT, Thomas Stuefe wrote: >> Fixed access modifier of `isExtendedAttributesEnabled` which has been moved to super class. > > Looks good to me, and Arno tested it. Thanks for the quick response! > > I think this falls under the trivial rule, which means you can integrate it right away without having to wait 24hrs. > > Thanks, Thomas @tstuefe Can you sponsor this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/2805 From github.com+1204330+overheadhunter at openjdk.java.net Wed Mar 3 12:23:14 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Wed, 3 Mar 2021 12:23:14 GMT Subject: Integrated: JDK-8262926 JDK-8260966 broke AIX build In-Reply-To: References: Message-ID: <96UUXXB5OXOh7Gf2aIBoNaCtVCThzt9TB1ZH6OUBkxo=.17289639-2777-47f0-940d-a3b7cdd0fd2d@github.com> On Wed, 3 Mar 2021 07:31:35 GMT, Sebastian Stenzel wrote: > Fixed access modifier of `isExtendedAttributesEnabled` which has been moved to super class. This pull request has now been integrated. Changeset: bf90e857 Author: Sebastian Stenzel Committer: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/bf90e857 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8262926: JDK-8260966 broke AIX build Reviewed-by: stuefe, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/2805 From azeller at openjdk.java.net Wed Mar 3 14:48:01 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Wed, 3 Mar 2021 14:48:01 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 [v2] In-Reply-To: References: Message-ID: > FileStore.supportsFileAttributeView might return a wrong value for ext3 mounts. In case of newer Linux distributions the extended attributes are enabled by default for ext3 mounts and do not show up /proc/mounts. > Currently the mount table is parsed to determine whether the mount options contain user_xattr or nouser_xattr. In case of neither entry it is expected that extended attributes are not supported on ext3. > > This change will for ext3 always probe the fs if none of the options above are found. This should ensure that we return the right value. Arno Zeller has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Removed special handling for ext4 too - Merge remote-tracking branch 'upstream/master' into LinuxFileStore - Fix ext3 detection in LinuxFileStore ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2778/files - new: https://git.openjdk.java.net/jdk/pull/2778/files/5fffc8d5..429663ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2778&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2778&range=00-01 Stats: 4540 lines in 166 files changed: 2670 ins; 1390 del; 480 mod Patch: https://git.openjdk.java.net/jdk/pull/2778.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2778/head:pull/2778 PR: https://git.openjdk.java.net/jdk/pull/2778 From clanger at openjdk.java.net Wed Mar 3 14:52:40 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 3 Mar 2021 14:52:40 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: References: <812qIf_aik1xc-ETE8wnsq5Y-QNfHnM3mcuFzjuWI7Y=.aebeb5df-5bc4-40a8-a06f-32c076768fd2@github.com> <5Wyu_CG-ryr-YXuuRYt5xRdq0q5Lb6miWcPXjVM7yCI=.5df23349-841f-4406-945d-8e0b269f8463@github.com> Message-ID: <6aedQKZ_jg5bK5t0yP0CdX_fTRK8O818780oBc0A_G4=.72e8c12b-a87c-4233-8f82-3c0174a45875@github.com> On Wed, 3 Mar 2021 11:31:23 GMT, Christoph Langer wrote: >> I can add that RHEL 8.3 also has extended attributes as default mount option for ext3 and will not show up in /proc/mounts. >> >> To me it seems that the default was changed some time ago, but it might not be so easy to find a kernel version that enabled it by default as it was in case of ext4. >> >> And even if we could find a kernel version that started to use it as default, it might still be possible to disable it during build time or by setting default mount options on the ext3 filesystem with tune2fs. These will also not show up in /proc/mounts (just checked on RHEL 8.3): >> >>> #tune2fs -l /dev/sdb1 | grep "Default mount" >> Default mount options: **user_xattr** acl >> #cat /proc/mounts | grep /dev/sdb1 >> >> >> And this is the same for ext4. >> >> I think the only save way to determine the support is to check on the filesystem. What do you think? > > I also think that if we were to do it right, we should go with always probing. @ArnoZeller, can you try that out in our test landscape? Alternatively, if there's a reason against always probing, maybe we could add an option to enable probing? The latest changes remove the ext3/ext4 special handling and we should end up in probing. Let's see what the outcome of testing will be. If we were to do it like that, getKernelVersion() can be removed then as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From alanb at openjdk.java.net Wed Mar 3 14:56:45 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 3 Mar 2021 14:56:45 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 [v2] In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 14:48:01 GMT, Arno Zeller wrote: >> FileStore.supportsFileAttributeView might return a wrong value for ext3 mounts. In case of newer Linux distributions the extended attributes are enabled by default for ext3 mounts and do not show up /proc/mounts. >> Currently the mount table is parsed to determine whether the mount options contain user_xattr or nouser_xattr. In case of neither entry it is expected that extended attributes are not supported on ext3. >> >> This change removes the special handling for ext3 and ext4 and will always probe the fs if none of the options above are found. This should ensure that we return the right value. > > Arno Zeller has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Removed special handling for ext4 too > - Merge remote-tracking branch 'upstream/master' into LinuxFileStore > - Fix ext3 detection in LinuxFileStore src/java.base/linux/classes/sun/nio/fs/LinuxFileStore.java line 144: > 142: } > 143: > 144: // no other information available so probe mount point You've removed the special handling for ext4 too, did you mean to do that? I think we'll need to do a lot of testing with this change as I suspect it going to bite back in some unusual configurations. ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From Alan.Bateman at oracle.com Wed Mar 3 16:54:51 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Mar 2021 16:54:51 +0000 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: References: Message-ID: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> On 02/03/2021 15:13, Sebastian Stenzel wrote: > Following up on JDK-8260966, I'd like to propose two further (independent) changes: > > 1. Fail fast in UnixFileStore.isExtendedAttributesEnabled(UnixPath path) [1], if UnixNativeDispatcher.c is incapable of handling xattr, thus avoid unnecessary I/O. > > 2. Refactor UnixUserDefinedFileAttributeView.java with these goals: > - deduplicate code > - reduce branching and improve readability > - fix leaking NativeBuffer by applying try-with-resource where applicable > - fix UnsupportedOperationException if trying to read to a Buffer that doesn't provide a backing array > > I'd need someones assistance to create a bunch of issues for these tasks. I can provide an issue description on this mailing list, but I don't have access to the issue tracker. > I've created the following two issues for the above, we might want another one to mechanically change the usages of NativeBuffer from try-finally to try-with-resources. https://bugs.openjdk.java.net/browse/JDK-8262957 https://bugs.openjdk.java.net/browse/JDK-8262958 Since you've contributed several changes in this area then we should see about getting you author role so that you get access to JBS. -Alan From alanb at openjdk.java.net Wed Mar 3 17:56:17 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 3 Mar 2021 17:56:17 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 [v3] In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 17:36:25 GMT, Arno Zeller wrote: >> FileStore.supportsFileAttributeView might return a wrong value for ext3 mounts. In case of newer Linux distributions the extended attributes are enabled by default for ext3 mounts and do not show up /proc/mounts. >> Currently the mount table is parsed to determine whether the mount options contain user_xattr or nouser_xattr. In case of neither entry it is expected that extended attributes are not supported on ext3. >> >> This change removes the special handling for ext3 and ext4 and will always probe the fs if none of the options above are found. This should ensure that we return the right value. > > Arno Zeller has updated the pull request incrementally with one additional commit since the last revision: > > Roll back ext4 changes Thanks for the analysis. I think we've converged and we are in agreement that we are forced to remove the special handing of ext3. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2778 From azeller at openjdk.java.net Wed Mar 3 17:56:16 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Wed, 3 Mar 2021 17:56:16 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 [v3] In-Reply-To: References: Message-ID: > FileStore.supportsFileAttributeView might return a wrong value for ext3 mounts. In case of newer Linux distributions the extended attributes are enabled by default for ext3 mounts and do not show up /proc/mounts. > Currently the mount table is parsed to determine whether the mount options contain user_xattr or nouser_xattr. In case of neither entry it is expected that extended attributes are not supported on ext3. > > This change removes the special handling for ext3 and ext4 and will always probe the fs if none of the options above are found. This should ensure that we return the right value. Arno Zeller has updated the pull request incrementally with one additional commit since the last revision: Roll back ext4 changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2778/files - new: https://git.openjdk.java.net/jdk/pull/2778/files/429663ab..833f888e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2778&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2778&range=01-02 Stats: 17 lines in 1 file changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2778.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2778/head:pull/2778 PR: https://git.openjdk.java.net/jdk/pull/2778 From azeller at openjdk.java.net Wed Mar 3 17:56:19 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Wed, 3 Mar 2021 17:56:19 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 [v2] In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 14:54:08 GMT, Alan Bateman wrote: >> Arno Zeller has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Removed special handling for ext4 too >> - Merge remote-tracking branch 'upstream/master' into LinuxFileStore >> - Fix ext3 detection in LinuxFileStore > > src/java.base/linux/classes/sun/nio/fs/LinuxFileStore.java line 144: > >> 142: } >> 143: >> 144: // no other information available so probe mount point > > You've removed the special handling for ext4 too, did you mean to do that? I think we'll need to do a lot of testing with this change as I suspect it going to bite back in some unusual configurations. Yes the change was intentional. I thought that ext4 has the same issues as ext3 and it might be possible to change the mount options or default mount options for ext4 with tune2fs to contain nouser_xattr. In this case the JDK would not detect that extended attributes are not supported. But I must admit that I just falsified my theory. tune2fs does not allow nouser_xattr as mount option. So for ext4 it can only be that someone uses a kernel that was configured to not support extended attributes on ext4 - this might not occur in real life. I will revert the change back to the original first change. ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From clanger at openjdk.java.net Wed Mar 3 17:58:43 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 3 Mar 2021 17:58:43 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 [v3] In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 17:56:16 GMT, Arno Zeller wrote: >> FileStore.supportsFileAttributeView might return a wrong value for ext3 mounts. In case of newer Linux distributions the extended attributes are enabled by default for ext3 mounts and do not show up /proc/mounts. >> Currently the mount table is parsed to determine whether the mount options contain user_xattr or nouser_xattr. In case of neither entry it is expected that extended attributes are not supported on ext3. >> >> This change removes the special handling for ext3 and ext4 and will always probe the fs if none of the options above are found. This should ensure that we return the right value. > > Arno Zeller has updated the pull request incrementally with one additional commit since the last revision: > > Roll back ext4 changes Marked as reviewed by clanger (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From bpb at openjdk.java.net Wed Mar 3 18:05:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 3 Mar 2021 18:05:41 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 [v3] In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 17:56:16 GMT, Arno Zeller wrote: >> FileStore.supportsFileAttributeView might return a wrong value for ext3 mounts. In case of newer Linux distributions the extended attributes are enabled by default for ext3 mounts and do not show up /proc/mounts. >> Currently the mount table is parsed to determine whether the mount options contain user_xattr or nouser_xattr. In case of neither entry it is expected that extended attributes are not supported on ext3. >> >> This change removes the special handling for ext3 and ext4 and will always probe the fs if none of the options above are found. This should ensure that we return the right value. > > Arno Zeller has updated the pull request incrementally with one additional commit since the last revision: > > Roll back ext4 changes Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From github.com+1204330+overheadhunter at openjdk.java.net Wed Mar 3 22:23:54 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Wed, 3 Mar 2021 22:23:54 GMT Subject: RFR: JDK-8262957 Fail fast in UnixFileStore.isExtendedAttributesEnabled Message-ID: Added new capability flag `UnixNativeDispatcher.SUPPORTS_XATTR`, which gets set `#ifdef _SYS_XATTR_H_`. Note that `_SYS_XATTR_H_` is defined in `xattr.h` in both [macOS/Darwin](https://github.com/apple/darwin-xnu/blob/main/bsd/sys/xattr.h), [Linux and GNU-based BSD systems using glibc](https://github.com/bminor/glibc/blob/master/misc/sys/xattr.h). It might not be defined for other operating systems that still support xattr. So if OpenJDK eventually adds support for further platforms, this might need to be adjusted as well. If xattr capabilities are missing, `UnixFileStore.isExtendedAttributesEnabled` will return false immediately, avoiding any I/O. As a side effect of this change, I redefined some other (private) capabilities. Strictly speaking, this change is not required but keeps the code consistent, as [previously discussed in the mailing list](https://mail.openjdk.java.net/pipermail/nio-dev/2021-February/008133.html). ------------- Commit messages: - Fail fast in UnixFileStore.isExtendedAttributesEnabled if UnixNativeDispatcher doesn't support xattr Changes: https://git.openjdk.java.net/jdk/pull/2816/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2816&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262957 Stats: 21 lines in 3 files changed: 19 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2816/head:pull/2816 PR: https://git.openjdk.java.net/jdk/pull/2816 From bpb at openjdk.java.net Thu Mar 4 02:13:46 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 4 Mar 2021 02:13:46 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 22:15:38 GMT, Sebastian Stenzel wrote: > Added new capability flag `UnixNativeDispatcher.SUPPORTS_XATTR`, which gets set `#ifdef _SYS_XATTR_H_`. > > Note that `_SYS_XATTR_H_` is defined in `xattr.h` in both [macOS/Darwin](https://github.com/apple/darwin-xnu/blob/main/bsd/sys/xattr.h), [Linux and GNU-based BSD systems using glibc](https://github.com/bminor/glibc/blob/master/misc/sys/xattr.h). It might not be defined for other operating systems that still support xattr. So if OpenJDK eventually adds support for further platforms, this might need to be adjusted as well. > > If xattr capabilities are missing, `UnixFileStore.isExtendedAttributesEnabled` will return false immediately, avoiding any I/O. > > As a side effect of this change, I redefined some other (private) capabilities. Strictly speaking, this change is not required but keeps the code consistent, as [previously discussed in the mailing list](https://mail.openjdk.java.net/pipermail/nio-dev/2021-February/008133.html). I think this look all right. I'll withhold approving until @AlanBateman has commented. ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From alanb at openjdk.java.net Thu Mar 4 15:17:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 4 Mar 2021 15:17:40 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: References: Message-ID: <3oC7RYLaLrQGrEdqrGV9oSIs_hQbY8GVuVg9SL9_v1M=.d809d1cf-9474-4177-a008-773c69f60354@github.com> On Wed, 3 Mar 2021 22:15:38 GMT, Sebastian Stenzel wrote: > Added new capability flag `UnixNativeDispatcher.SUPPORTS_XATTR`, which gets set `#ifdef _SYS_XATTR_H_`. > > Note that `_SYS_XATTR_H_` is defined in `xattr.h` in both [macOS/Darwin](https://github.com/apple/darwin-xnu/blob/main/bsd/sys/xattr.h), [Linux and GNU-based BSD systems using glibc](https://github.com/bminor/glibc/blob/master/misc/sys/xattr.h). It might not be defined for other operating systems that still support xattr. So if OpenJDK eventually adds support for further platforms, this might need to be adjusted as well. > > If xattr capabilities are missing, `UnixFileStore.isExtendedAttributesEnabled` will return false immediately, avoiding any I/O. > > As a side effect of this change, I redefined some other (private) capabilities. Strictly speaking, this change is not required but keeps the code consistent, as [previously discussed in the mailing list](https://mail.openjdk.java.net/pipermail/nio-dev/2021-February/008133.html). src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java line 186: > 184: return false; > 185: } > 186: Add SUPPORTS_XATTR is a good idea. Style-wise, it might be a bit neater to use if (UnixNativeDispatcher.xattrSupported()) { ...} so there will only one "return false" code path. Looking at this code now make me wonder about the close(fd) for the case that the open fails. It should be checking if fd or there should be a nested try-finally so that close is only invoked when the open succeeds. ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From github.com+1204330+overheadhunter at openjdk.java.net Thu Mar 4 15:30:40 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Thu, 4 Mar 2021 15:30:40 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: <3oC7RYLaLrQGrEdqrGV9oSIs_hQbY8GVuVg9SL9_v1M=.d809d1cf-9474-4177-a008-773c69f60354@github.com> References: <3oC7RYLaLrQGrEdqrGV9oSIs_hQbY8GVuVg9SL9_v1M=.d809d1cf-9474-4177-a008-773c69f60354@github.com> Message-ID: <5zypJQRKllJ-CTbg2rNjwyOwWx1bEnc24dbszBCDsNc=.716bd821-0e38-4252-85d7-eeb8907446af@github.com> On Thu, 4 Mar 2021 15:15:00 GMT, Alan Bateman wrote: > Style-wise, it might be a bit neater to use if (UnixNativeDispatcher.xattrSupported()) { ...} so there will only one "return false" code path. I prefer to avoid nested blocks for improved readability, but thats mostly a matter of taste. If you like, I can reverse the "if". > Looking at this code now make me wonder about the close(fd) for the case that the open fails. It should be checking if fd or there should be a nested try-finally so that close is only invoked when the open succeeds. True. But I guess that would be off-topic in this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From alanb at openjdk.java.net Thu Mar 4 20:28:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 4 Mar 2021 20:28:40 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: <5zypJQRKllJ-CTbg2rNjwyOwWx1bEnc24dbszBCDsNc=.716bd821-0e38-4252-85d7-eeb8907446af@github.com> References: <3oC7RYLaLrQGrEdqrGV9oSIs_hQbY8GVuVg9SL9_v1M=.d809d1cf-9474-4177-a008-773c69f60354@github.com> <5zypJQRKllJ-CTbg2rNjwyOwWx1bEnc24dbszBCDsNc=.716bd821-0e38-4252-85d7-eeb8907446af@github.com> Message-ID: On Thu, 4 Mar 2021 15:27:56 GMT, Sebastian Stenzel wrote: >> src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java line 186: >> >>> 184: return false; >>> 185: } >>> 186: >> >> Add SUPPORTS_XATTR is a good idea. >> Style-wise, it might be a bit neater to use if (UnixNativeDispatcher.xattrSupported()) { ...} so there will only one "return false" code path. >> Looking at this code now make me wonder about the close(fd) for the case that the open fails. It should be checking if fd or there should be a nested try-finally so that close is only invoked when the open succeeds. > >> Style-wise, it might be a bit neater to use if (UnixNativeDispatcher.xattrSupported()) { ...} so there will only one "return false" code path. > > I prefer to avoid nested blocks for improved readability, but thats mostly a matter of taste. If you like, I can reverse the "if". > >> Looking at this code now make me wonder about the close(fd) for the case that the open fails. It should be checking if fd or there should be a nested try-finally so that close is only invoked when the open succeeds. > > True. But I guess that would be off-topic in this PR? It's somewhat subjective. What you have is fine, I just would have done is differently to avoid too many return paths. I think we should clean up the close(-1) case while we are in the area, separate PR of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 5 06:55:02 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 5 Mar 2021 06:55:02 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: References: <3oC7RYLaLrQGrEdqrGV9oSIs_hQbY8GVuVg9SL9_v1M=.d809d1cf-9474-4177-a008-773c69f60354@github.com> <5zypJQRKllJ-CTbg2rNjwyOwWx1bEnc24dbszBCDsNc=.716bd821-0e38-4252-85d7-eeb8907446af@github.com> Message-ID: On Thu, 4 Mar 2021 20:25:48 GMT, Alan Bateman wrote: >>> Style-wise, it might be a bit neater to use if (UnixNativeDispatcher.xattrSupported()) { ...} so there will only one "return false" code path. >> >> I prefer to avoid nested blocks for improved readability, but thats mostly a matter of taste. If you like, I can reverse the "if". >> >>> Looking at this code now make me wonder about the close(fd) for the case that the open fails. It should be checking if fd or there should be a nested try-finally so that close is only invoked when the open succeeds. >> >> True. But I guess that would be off-topic in this PR? > > It's somewhat subjective. What you have is fine, I just would have done is differently to avoid too many return paths. > > I think we should clean up the close(-1) case while we are in the area, separate PR of course. All right, will you create another bug report for the `close(-1)` issue? ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From azeller at openjdk.java.net Fri Mar 5 11:02:49 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Fri, 5 Mar 2021 11:02:49 GMT Subject: RFR: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 [v3] In-Reply-To: References: Message-ID: On Wed, 3 Mar 2021 17:35:03 GMT, Alan Bateman wrote: > Thanks for the analysis. I think we've converged and we are in agreement that we are forced to remove the special handing of ext3. @AlanBateman, @RealCLanger, @bplb : Thanks for the reviews! I am no committer and therefore I will need a sponsor. ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From azeller at openjdk.java.net Fri Mar 5 11:05:48 2021 From: azeller at openjdk.java.net (Arno Zeller) Date: Fri, 5 Mar 2021 11:05:48 GMT Subject: Integrated: 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 In-Reply-To: References: Message-ID: On Mon, 1 Mar 2021 10:00:43 GMT, Arno Zeller wrote: > FileStore.supportsFileAttributeView might return a wrong value for ext3 mounts. In case of newer Linux distributions the extended attributes are enabled by default for ext3 mounts and do not show up /proc/mounts. > Currently the mount table is parsed to determine whether the mount options contain user_xattr or nouser_xattr. In case of neither entry it is expected that extended attributes are not supported on ext3. > > This change removes the special handling for ext3 and ext4 and will always probe the fs if none of the options above are found. This should ensure that we return the right value. This pull request has now been integrated. Changeset: 8d3de4b1 Author: Arno Zeller Committer: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/8d3de4b1 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod 8262844: (fs) FileStore.supportsFileAttributeView might return false negative in case of ext3 Reviewed-by: alanb, clanger, bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/2778 From github.com+741251+turbanoff at openjdk.java.net Sun Mar 7 20:31:08 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Sun, 7 Mar 2021 20:31:08 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v11] In-Reply-To: References: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com> Message-ID: On Fri, 19 Feb 2021 15:03:11 GMT, Sean Mullan wrote: >> As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code: >> >> PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); >> private static List parsePKCS7(InputStream is) >> certs = parsePKCS7(is); >> public X509CertPath(InputStream is, String encoding) >> return new X509CertPath(new ByteArrayInputStream(data), encoding); >> >> PKCS7 pkcs7 = new PKCS7(is.readAllBytes()); >> private static List parsePKCS7(InputStream is) >> certs = parsePKCS7(is); >> public X509CertPath(InputStream is, String encoding) >> this(is, PKIPATH_ENCODING); >> public X509CertPath(InputStream is) throws CertificateException { >> return new X509CertPath(new ByteArrayInputStream(encoding)); >> >> ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png) >> >> Perhaps original marking approach was lost during refactoring? > > You are right, the code was refactored (way back in 2010) [1] to read one block at a time, so this check on mark can be removed. So, in this case, I think it is probably safe to just pass the InputStream as-is to PKCS7(InputStream), but maybe you can add a comment that says this should always be a ByteArrayInputStream. We can look at refactoring this code and clean it up a bit more later. > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/337ae296b6d6 I find implementation of `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)` a bit confusing (or even buggy). It uses only `InputStream.available()` to parse block. So I would prefer to not use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From bpb at openjdk.java.net Tue Mar 9 22:26:26 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 9 Mar 2021 22:26:26 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced Message-ID: Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `slice()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. ------------- Commit messages: - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced Changes: https://git.openjdk.java.net/jdk/pull/2902/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-4833719 Stats: 217 lines in 3 files changed: 204 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/2902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2902/head:pull/2902 PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Wed Mar 10 03:42:24 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 10 Mar 2021 03:42:24 GMT Subject: RFR: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files Message-ID: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Please review this proposed change to make it simpler to navigate to a principal method from a convenience method. This change does not appear to rise to the level of requiring a CSR as it involves changes such as `
invocation
` and `{@code invocation}` to `{@link target invocation}`. ------------- Commit messages: - 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files Changes: https://git.openjdk.java.net/jdk/pull/2904/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2904&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259218 Stats: 31 lines in 1 file changed: 8 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/2904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2904/head:pull/2904 PR: https://git.openjdk.java.net/jdk/pull/2904 From adinn at openjdk.java.net Wed Mar 10 10:15:06 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Wed, 10 Mar 2021 10:15:06 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced In-Reply-To: References: Message-ID: <0D4TrhDG9TocjIyXQspgWkA2gSJQWnadRRd3KSRwBv8=.b5ad1781-413a-44b1-83d5-353e4f009f8f@github.com> On Tue, 9 Mar 2021 22:20:52 GMT, Brian Burkhalter wrote: > Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. > > The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `slice()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) > > In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. > > A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. > > Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. This looks good. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2902 From dfuchs at openjdk.java.net Wed Mar 10 11:41:07 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 10 Mar 2021 11:41:07 GMT Subject: RFR: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files In-Reply-To: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> References: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Message-ID: On Wed, 10 Mar 2021 03:12:31 GMT, Brian Burkhalter wrote: > Please review this proposed change to make it simpler to navigate to a principal method from a convenience method. > > This change does not appear to rise to the level of requiring a CSR as it involves changes such as `
invocation
` and `{@code invocation}` to `{@link target invocation}`. src/java.base/share/classes/java/nio/file/Files.java line 2854: > 2852: *
{@link > 2853: * walkFileTree(Path, Set, int, FileVisitor) > 2854: * walkFileTree(start, EnumSet.noneOf(FileVisitOption.class), Integer.MAX_VALUE, visitor) Because all methods in `Files` are static, and because the text speaks of "evaluating an expression" and is formatted as a code block (rather than as an inline reference), I wonder if you shouldn't add the `Files.` prefix here, and keep it in all the other snippets rather than removing it. Also - doesn't the link target need to start with a hash sign? I mean: {@link #walkFileTree(Path, Set, int, FileVisitor) ... } best regards, -- daniel ------------- PR: https://git.openjdk.java.net/jdk/pull/2904 From sebastian.stenzel at gmail.com Wed Mar 10 16:42:08 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 10 Mar 2021 17:42:08 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> References: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> Message-ID: <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> > On 3. Mar 2021, at 17:54, Alan Bateman wrote: > > On 02/03/2021 15:13, Sebastian Stenzel wrote: >> Following up on JDK-8260966, I'd like to propose two further (independent) changes: >> >> 1. Fail fast in UnixFileStore.isExtendedAttributesEnabled(UnixPath path) [1], if UnixNativeDispatcher.c is incapable of handling xattr, thus avoid unnecessary I/O. >> >> 2. Refactor UnixUserDefinedFileAttributeView.java with these goals: >> - deduplicate code >> - reduce branching and improve readability >> - fix leaking NativeBuffer by applying try-with-resource where applicable >> - fix UnsupportedOperationException if trying to read to a Buffer that doesn't provide a backing array >> >> I'd need someones assistance to create a bunch of issues for these tasks. I can provide an issue description on this mailing list, but I don't have access to the issue tracker. >> > I've created the following two issues for the above, we might want another one to mechanically change the usages of NativeBuffer from try-finally to try-with-resources. > > https://bugs.openjdk.java.net/browse/JDK-8262957 > https://bugs.openjdk.java.net/browse/JDK-8262958 > > Since you've contributed several changes in this area then we should see about getting you author role so that you get access to JBS. > > -Alan I started working on JDK-8262958 as well, now. Since it will contain multiple changes that build upon each other, I want to ask how to deal with it. My suggestion: I keep this PR a draft for now and have you review each change for itself. Or does it _need_ to be marked RFR to spit out individual webrevs? https://github.com/openjdk/jdk/pull/2916 From Alan.Bateman at oracle.com Wed Mar 10 16:47:32 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Mar 2021 16:47:32 +0000 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> References: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> Message-ID: On 10/03/2021 16:42, Sebastian Stenzel wrote: > I started working on JDK-8262958 as well, now. Since it will contain multiple changes that build upon each other, I want to ask how to deal with it. > > My suggestion: I keep this PR a draft for now and have you review each change for itself. Or does it _need_ to be marked RFR to spit out individual webrevs? Small changes are usually easier to review. So if it can be broken up in a sequence of small changes, each with its own JBS and PR, then it would be easier I think. -Alan From alanb at openjdk.java.net Wed Mar 10 16:57:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 10 Mar 2021 16:57:07 GMT Subject: RFR: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files In-Reply-To: References: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Message-ID: On Wed, 10 Mar 2021 11:37:57 GMT, Daniel Fuchs wrote: >> Please review this proposed change to make it simpler to navigate to a principal method from a convenience method. >> >> This change does not appear to rise to the level of requiring a CSR as it involves changes such as `
invocation
` and `{@code invocation}` to `{@link target invocation}`. > > src/java.base/share/classes/java/nio/file/Files.java line 2854: > >> 2852: *
{@link >> 2853: * walkFileTree(Path, Set, int, FileVisitor) >> 2854: * walkFileTree(start, EnumSet.noneOf(FileVisitOption.class), Integer.MAX_VALUE, visitor) > > Because all methods in `Files` are static, and because the text speaks of "evaluating an expression" and is formatted as a code block (rather than as an inline reference), I wonder if you shouldn't add the `Files.` prefix here, and keep it in all the other snippets rather than removing it. > Also - doesn't the link target need to start with a hash sign? I mean: > > {@link #walkFileTree(Path, Set, int, FileVisitor) > ... } > > best regards, > > -- daniel I think you right and adding "Files." to the label should mean it looks the same as before. ------------- PR: https://git.openjdk.java.net/jdk/pull/2904 From brian.burkhalter at oracle.com Wed Mar 10 17:06:05 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Mar 2021 09:06:05 -0800 Subject: RFR: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files In-Reply-To: References: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Message-ID: <95B12CDD-245F-4810-8BE0-0F20CF2A344E@oracle.com> > On Mar 10, 2021, at 3:41 AM, Daniel Fuchs wrote: > > src/java.base/share/classes/java/nio/file/Files.java line 2854: > >> 2852: *
{@link >> 2853: * walkFileTree(Path, Set, int, FileVisitor) >> 2854: * walkFileTree(start, EnumSet.noneOf(FileVisitOption.class), Integer.MAX_VALUE, visitor) > > Because all methods in `Files` are static, and because the text speaks of "evaluating an expression" and is formatted as a code block (rather than as an inline reference), I wonder if you shouldn't add the `Files.` prefix here, and keep it in all the other snippets rather than removing it. OK I will put it back for the code block cases. > Also - doesn't the link target need to start with a hash sign? I mean: > > {@link #walkFileTree(Path, Set, int, FileVisitor) > ? } No, it does not. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Mar 10 17:07:43 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Mar 2021 09:07:43 -0800 Subject: RFR: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files In-Reply-To: References: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Message-ID: > On Mar 10, 2021, at 8:57 AM, Alan Bateman wrote: > >> Because all methods in `Files` are static, and because the text speaks of "evaluating an expression" and is formatted as a code block (rather than as an inline reference), I wonder if you shouldn't add the `Files.` prefix here, and keep it in all the other snippets rather than removing it. >> Also - doesn't the link target need to start with a hash sign? I mean: >> >> {@link #walkFileTree(Path, Set, int, FileVisitor) >> ... } >> >> best regards, >> >> -- daniel > > I think you right and adding "Files." to the label should mean it looks the same as before. It was inconsistent before. I?ll add ?Files? to the blockquote cases but not inline. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.stenzel at gmail.com Wed Mar 10 17:23:57 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 10 Mar 2021 18:23:57 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: References: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> Message-ID: <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> > On 10. Mar 2021, at 17:47, Alan Bateman wrote: > > On 10/03/2021 16:42, Sebastian Stenzel wrote: >> I started working on JDK-8262958 as well, now. Since it will contain multiple changes that build upon each other, I want to ask how to deal with it. >> >> My suggestion: I keep this PR a draft for now and have you review each change for itself. Or does it _need_ to be marked RFR to spit out individual webrevs? > Small changes are usually easier to review. So if it can be broken up in a sequence of small changes, each with its own JBS and PR, then it would be easier I think. > > -Alan Is there no way to review increments? After all, JDK-8262958 addresses several related tasks. All we would need is a way to review individual commits instead of the PR as a whole. But yes, we certainly can subdivide it further: I'd need you to replace JDK-8262958 by a three more issues: 1. Deduplicate code around `flistxattr` calls inside of UnixUserDefinedFileAttributeView.java 2. Fix UnsupportedOperationException when passing a ByteBuffer without a backing array to `UnixUserDefinedFileAttributeView.read(String name, ByteBuffer dst)` 3. Use try-with-resource for all NativeBuffers within UnixUserDefinedFileAttributeView, fixing leak when opening a file for read/write attr fails (in lines [1] and [2]) [1]: https://github.com/openjdk/jdk/blob/7e52a6e8b37412b43b0024ca067959100c14f508/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L187 [2]: https://github.com/openjdk/jdk/blob/7e52a6e8b37412b43b0024ca067959100c14f508/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L258 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Wed Mar 10 17:28:23 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 10 Mar 2021 17:28:23 GMT Subject: RFR: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files [v2] In-Reply-To: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> References: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Message-ID: > Please review this proposed change to make it simpler to navigate to a principal method from a convenience method. > > This change does not appear to rise to the level of requiring a CSR as it involves changes such as `
invocation
` and `{@code invocation}` to `{@link target invocation}`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8259218: Add Files to link text in block quotes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2904/files - new: https://git.openjdk.java.net/jdk/pull/2904/files/47a0734e..674720c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2904&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2904&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/2904.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2904/head:pull/2904 PR: https://git.openjdk.java.net/jdk/pull/2904 From dfuchs at openjdk.java.net Wed Mar 10 17:32:11 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 10 Mar 2021 17:32:11 GMT Subject: RFR: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files [v2] In-Reply-To: References: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Message-ID: On Wed, 10 Mar 2021 17:28:23 GMT, Brian Burkhalter wrote: >> Please review this proposed change to make it simpler to navigate to a principal method from a convenience method. >> >> This change does not appear to rise to the level of requiring a CSR as it involves changes such as `
invocation
` and `{@code invocation}` to `{@link target invocation}`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8259218: Add Files to link text in block quotes The new changes LGTM. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2904 From sebastian.stenzel at gmail.com Wed Mar 10 17:37:42 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 10 Mar 2021 18:37:42 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> References: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> Message-ID: <73A1CBF3-3434-4576-ABAA-F1AC87822568@gmail.com> > On 10. Mar 2021, at 18:23, Sebastian Stenzel wrote: > >> On 10. Mar 2021, at 17:47, Alan Bateman > wrote: >> >> On 10/03/2021 16:42, Sebastian Stenzel wrote: >>> I started working on JDK-8262958 as well, now. Since it will contain multiple changes that build upon each other, I want to ask how to deal with it. >>> >>> My suggestion: I keep this PR a draft for now and have you review each change for itself. Or does it _need_ to be marked RFR to spit out individual webrevs? >> Small changes are usually easier to review. So if it can be broken up in a sequence of small changes, each with its own JBS and PR, then it would be easier I think. >> >> -Alan > > > Is there no way to review increments? After all, JDK-8262958 addresses several related tasks. All we would need is a way to review individual commits instead of the PR as a whole. > > But yes, we certainly can subdivide it further: I'd need you to replace JDK-8262958 by a three more issues: > > 1. Deduplicate code around `flistxattr` calls inside of UnixUserDefinedFileAttributeView.java > 2. Fix UnsupportedOperationException when passing a ByteBuffer without a backing array to `UnixUserDefinedFileAttributeView.read(String name, ByteBuffer dst)` > 3. Use try-with-resource for all NativeBuffers within UnixUserDefinedFileAttributeView, fixing leak when opening a file for read/write attr fails (in lines [1] and [2]) > > [1]: https://github.com/openjdk/jdk/blob/7e52a6e8b37412b43b0024ca067959100c14f508/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L187 > [2]: https://github.com/openjdk/jdk/blob/7e52a6e8b37412b43b0024ca067959100c14f508/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L258 Oh, and last but not least: 4. Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java (as it is currently kind of random, as we've already discussed in a previous review) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.java.net Wed Mar 10 17:53:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 10 Mar 2021 17:53:08 GMT Subject: RFR: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files [v2] In-Reply-To: References: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Message-ID: On Wed, 10 Mar 2021 17:28:23 GMT, Brian Burkhalter wrote: >> Please review this proposed change to make it simpler to navigate to a principal method from a convenience method. >> >> This change does not appear to rise to the level of requiring a CSR as it involves changes such as `
invocation
` and `{@code invocation}` to `{@link target invocation}`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8259218: Add Files to link text in block quotes Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2904 From bpb at openjdk.java.net Wed Mar 10 20:05:09 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 10 Mar 2021 20:05:09 GMT Subject: Integrated: 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files In-Reply-To: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> References: <-5Ve030J_BqvFVaAkgEsGApEc5J81nbXESJMnlSgs_Y=.8753843b-3ac2-4a26-943e-4324b1dcf9cb@github.com> Message-ID: <5RTepxXe-bho3rCM6NbSJ8TEw7Eotdga8Y1oDvhtFeA=.86116336-0a14-4780-8ff7-b86f3780c65f@github.com> On Wed, 10 Mar 2021 03:12:31 GMT, Brian Burkhalter wrote: > Please review this proposed change to make it simpler to navigate to a principal method from a convenience method. > > This change does not appear to rise to the level of requiring a CSR as it involves changes such as `
invocation
` and `{@code invocation}` to `{@link target invocation}`. This pull request has now been integrated. Changeset: b482733f Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/b482733f Stats: 29 lines in 1 file changed: 8 ins; 0 del; 21 mod 8259218: (fs) Add links in from overloaded methods in java.nio.file.Files Reviewed-by: dfuchs, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2904 From sebastian.stenzel at gmail.com Wed Mar 10 21:20:52 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 10 Mar 2021 22:20:52 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> References: <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> Message-ID: <47712854-6204-46C2-A64A-A068B8CBFB6E@gmail.com> Resending from my phone, as I think the mailing list failed to process mime format from Apple Mail. > Am 10.03.2021 um 18:23 schrieb Sebastian Stenzel : > > ? >> On 10. Mar 2021, at 17:47, Alan Bateman wrote: >> >>> On 10/03/2021 16:42, Sebastian Stenzel wrote: >>> I started working on JDK-8262958 as well, now. Since it will contain multiple changes that build upon each other, I want to ask how to deal with it. >>> >>> My suggestion: I keep this PR a draft for now and have you review each change for itself. Or does it _need_ to be marked RFR to spit out individual webrevs? >> Small changes are usually easier to review. So if it can be broken up in a sequence of small changes, each with its own JBS and PR, then it would be easier I think. >> >> -Alan > > > Is there no way to review increments? After all, JDK-8262958 addresses several related tasks. All we would need is a way to review individual commits instead of the PR as a whole. > > But yes, we certainly can subdivide it further: I'd need you to replace JDK-8262958 by a three more issues: > > 1. Deduplicate code around `flistxattr` calls inside of UnixUserDefinedFileAttributeView.java > 2. Fix UnsupportedOperationException when passing a ByteBuffer without a backing array to `UnixUserDefinedFileAttributeView.read(String name, ByteBuffer dst)` > 3. Use try-with-resource for all NativeBuffers within UnixUserDefinedFileAttributeView, fixing leak when opening a file for read/write attr fails (in lines [1] and [2]) > > [1]: https://github.com/openjdk/jdk/blob/7e52a6e8b37412b43b0024ca067959100c14f508/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L187 > [2]: https://github.com/openjdk/jdk/blob/7e52a6e8b37412b43b0024ca067959100c14f508/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L258 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Thu Mar 11 03:00:08 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 11 Mar 2021 03:00:08 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v3] In-Reply-To: <_1vz3REF25jmuxPtmitx555D5BJ3JYDjQKX1C0YBKrY=.6c8b24b6-496b-4bcb-bab7-09f8266910a9@github.com> References: <_a8pVNR3nx206LObbkB6dAz1vQN4sjiKl1XDg3BH1nk=.80915065-2904-4ffe-9d09-ee6534aaa658@github.com> <5fL5lxIxwbuUOHNNNy0HdLA7aGQrm2sFlI__8K40pR4=.58429046-4783-4b6e-a3ff-4c1f3b3eedb6@github.com> <_1vz3REF25jmuxPtmitx555D5BJ3JYDjQKX1C0YBKrY=.6c8b24b6-496b-4bcb-bab7-09f8266910a9@github.com> Message-ID: On Wed, 24 Feb 2021 22:47:51 GMT, Brian Burkhalter wrote: >> Choice 3, the equivalent of getOrDefault, is compact and exposes explicitly the case where no extension is present with very little overhead. > > Most use cases appear to concern switching on the extension to select among several alternatives: > > - Get the file format name. > - Get an image reader to read a given image file. > - Get an icon to represent a given file in a file view. > - Select an application which can open a file of a certain type. > > For this a string-based `getExtension()` method would seem to be enough. It is unclear how a platform representation would add any value or even whether one could be self-consistent given that an extension is not really an element in the sense of a root component, directory, or file. Each of these represents an actual component in the file system whereas an extension could be considered a sort of attribute. > > Another related operation would be to remove the extension. A couple of uses of this are: > > - Input file `archive.zip` unzips to `archive/`. > - Input file `archive.tar.gz` gunzips to `archive.tar`. Next up for this one would be a test and CSR once the basic idea is agreed upon. Are there any more comments to this effect? ------------- PR: https://git.openjdk.java.net/jdk/pull/2319 From bpb at openjdk.java.net Thu Mar 11 03:04:07 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 11 Mar 2021 03:04:07 GMT Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test In-Reply-To: References: Message-ID: On Wed, 24 Feb 2021 17:29:58 GMT, Thomas Stuefe wrote: >> The test was based on the one in the issue. I have not coerced it to fail. It is designed to fail on Windows only in case we can catch the flush failure. As far as I am concerned the retry iteration count increase could be removed from this issue altogether and the flush failure addressed in a different issue after there are comments from Microsoft. The present issue in fact ought to be renamed to something like "Mapped memory force methods should be specified to throw UncheckedIOExcreption". > > Alan, Brian, thanks for the clarifications. > > Luckily, we have more participation from Microsoft than we had in the past, so the chance of getting feedback is higher. > > Cheers, Thomas Are there any more comments on this PR? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2636 From alanb at openjdk.java.net Thu Mar 11 13:27:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 11 Mar 2021 13:27:07 GMT Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test In-Reply-To: References: Message-ID: <66DqyNExDyUwGh2OWM7obz5ySIrANaOTt78D8FV59-8=.74d6c771-9bc5-475b-b8fe-54a59f8a1823@github.com> On Thu, 11 Mar 2021 03:00:57 GMT, Brian Burkhalter wrote: > Are there any more comments on this PR? Thanks. Not on the javadoc changes, I think that's useful to have. Did you manage to reproduce the issue that was reported? Did anyone from Microsoft comment as it looks like a Windows bug that several libraries have been forced to put in workarounds for. The changes to MemoryMemoryUtils add line breaks in 5-6 places that probably should be reverted. ------------- PR: https://git.openjdk.java.net/jdk/pull/2636 From brian.burkhalter at oracle.com Thu Mar 11 16:24:18 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Mar 2021 08:24:18 -0800 Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test In-Reply-To: <66DqyNExDyUwGh2OWM7obz5ySIrANaOTt78D8FV59-8=.74d6c771-9bc5-475b-b8fe-54a59f8a1823@github.com> References: <66DqyNExDyUwGh2OWM7obz5ySIrANaOTt78D8FV59-8=.74d6c771-9bc5-475b-b8fe-54a59f8a1823@github.com> Message-ID: <3D734742-A3E9-46B3-879D-B31BB8BF6059@oracle.com> > On Mar 11, 2021, at 5:27 AM, Alan Bateman wrote: > > On Thu, 11 Mar 2021 03:00:57 GMT, Brian Burkhalter > wrote: > >> Are there any more comments on this PR? Thanks. > > Not on the javadoc changes, I think that's useful to have. > > Did you manage to reproduce the issue that was reported? Not yet. > Did anyone from Microsoft comment as it looks like a Windows bug that several libraries have been forced to put in workarounds for. No. I will remind them. > The changes to MemoryMemoryUtils add line breaks in 5-6 places that probably should be reverted. Reverted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Thu Mar 11 16:26:32 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 11 Mar 2021 16:26:32 GMT Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test [v4] In-Reply-To: References: Message-ID: > This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 6539707: Revert line break suppression in MappedMemoryUtils ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2636/files - new: https://git.openjdk.java.net/jdk/pull/2636/files/e41ac28a..df27a1d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2636&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2636&range=02-03 Stats: 12 lines in 1 file changed: 0 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2636.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2636/head:pull/2636 PR: https://git.openjdk.java.net/jdk/pull/2636 From alanb at openjdk.java.net Fri Mar 12 11:26:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 12 Mar 2021 11:26:09 GMT Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test [v4] In-Reply-To: References: Message-ID: On Thu, 11 Mar 2021 16:26:32 GMT, Brian Burkhalter wrote: >> This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 6539707: Revert line break suppression in MappedMemoryUtils Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2636 From alanb at openjdk.java.net Fri Mar 12 11:26:10 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 12 Mar 2021 11:26:10 GMT Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test In-Reply-To: <66DqyNExDyUwGh2OWM7obz5ySIrANaOTt78D8FV59-8=.74d6c771-9bc5-475b-b8fe-54a59f8a1823@github.com> References: <66DqyNExDyUwGh2OWM7obz5ySIrANaOTt78D8FV59-8=.74d6c771-9bc5-475b-b8fe-54a59f8a1823@github.com> Message-ID: <6_pjQ09f-lx0zQJtOHQ4c6jMfWAv4qE6z_kmhuRGN28=.4a57d9b8-6d98-4d86-a377-453efca7dbe9@github.com> On Thu, 11 Mar 2021 13:24:12 GMT, Alan Bateman wrote: >> Are there any more comments on this PR? Thanks. > >> Are there any more comments on this PR? Thanks. > > Not on the javadoc changes, I think that's useful to have. > > Did you manage to reproduce the issue that was reported? Did anyone from Microsoft comment as it looks like a Windows bug that several libraries have been forced to put in workarounds for. > > The changes to MemoryMemoryUtils add line breaks in 5-6 places that probably should be reverted. Updated patch looks okay and means the spec covers the unlikely case that force can fail. It would be great if the Microsoft folks could engage on this issue as it screams of a Windows bug that several libraries and runtimes have had to be in workarounds for. ------------- PR: https://git.openjdk.java.net/jdk/pull/2636 From stuefe at openjdk.java.net Fri Mar 12 11:50:09 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 12 Mar 2021 11:50:09 GMT Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test [v4] In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 11:23:49 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 6539707: Revert line break suppression in MappedMemoryUtils > > Marked as reviewed by alanb (Reviewer). FWIW it looks good to me too (does what you said it would do). Lacking any information, we cannot do better. Would be nice to know e.g. if injecting a ms sleep would help instead of busy spinning into FlushViewOfFile in such a short succession. ------------- PR: https://git.openjdk.java.net/jdk/pull/2636 From brian.burkhalter at oracle.com Fri Mar 12 16:27:59 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Mar 2021 08:27:59 -0800 Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test In-Reply-To: <6_pjQ09f-lx0zQJtOHQ4c6jMfWAv4qE6z_kmhuRGN28=.4a57d9b8-6d98-4d86-a377-453efca7dbe9@github.com> References: <66DqyNExDyUwGh2OWM7obz5ySIrANaOTt78D8FV59-8=.74d6c771-9bc5-475b-b8fe-54a59f8a1823@github.com> <6_pjQ09f-lx0zQJtOHQ4c6jMfWAv4qE6z_kmhuRGN28=.4a57d9b8-6d98-4d86-a377-453efca7dbe9@github.com> Message-ID: <3598D2F5-C9AD-4B31-BAD6-273338CF0225@oracle.com> > On Mar 12, 2021, at 3:26 AM, Alan Bateman wrote: > > It would be great if the Microsoft folks could engage on this issue as it screams of a Windows bug that several libraries and runtimes have had to be in workarounds for. They are going to try to look into it in their next work phase starting Monday. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Mar 12 16:29:07 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Mar 2021 08:29:07 -0800 Subject: RFR: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test [v4] In-Reply-To: References: Message-ID: > On Mar 12, 2021, at 3:50 AM, Thomas Stuefe wrote: > > FWIW it looks good to me too (does what you said it would do). Lacking any information, we cannot do better. Would be nice to know e.g. if injecting a ms sleep would help instead of busy spinning into FlushViewOfFile in such a short succession. If we can obtain some more information from MS then perhaps a better solution can be devised, or eventually if FlushViewOfFile is fixed, tthe workaround removed altogether. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Fri Mar 12 21:33:18 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 12 Mar 2021 21:33:18 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v8] In-Reply-To: References: Message-ID: > Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`. > > The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.) > > All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension. > > Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero. > > The behavior of the proposed method for some example cases is as: > > . -> > .. -> > .a.b -> b > ...... -> > .....a -> a > ....a.b -> b > ..foo -> foo > test.rb -> rb > a/b/d/test.rb -> rb > .a/b/d/test.rb -> rb > foo. -> > test -> > .profile -> > .profile.sh -> sh > ..foo -> foo > .....foo -> foo > .vimrc -> > test. -> > test.. -> > test... -> > foo.tar.gz -> gz > foo.bar. -> > image.jpg -> jpg > music.mp3 -> mp3 > video.mp4 -> mp4 > document.txt -> txt > foo.tar.gz -> gz > foo.bar. -> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8057113: Change first sentence; change param name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2319/files - new: https://git.openjdk.java.net/jdk/pull/2319/files/0c864bd2..e380d09e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2319&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2319&range=06-07 Stats: 15 lines in 1 file changed: 0 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/2319.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2319/head:pull/2319 PR: https://git.openjdk.java.net/jdk/pull/2319 From rriggs at openjdk.java.net Fri Mar 12 22:11:11 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 12 Mar 2021 22:11:11 GMT Subject: RFR: 8057113: (fs) Path should have a method to obtain the filename extension [v8] In-Reply-To: References: Message-ID: <_pIRGB3RvQ70trXJ96X8etaF7ubyQ3mIebc_slqoz88=.344949c1-bf5f-404a-bf01-0577b999101b@github.com> On Fri, 12 Mar 2021 21:33:18 GMT, Brian Burkhalter wrote: >> Please review this proposed change to add a method `java.nio.file.Path.getExtension()`. This was initially discussed in the thread http://mail.openjdk.java.net/pipermail/nio-dev/2018-February/004716.html. This method would return the filename extension of the file name of the `Path`. The extension is defined to be the portion of the file name after the last dot `(?.?)`. >> >> The definitions of file extension for about fifteen platforms and languages were surveyed to try to find a reasonable compromise for the definition of extension. The most common definition was the last segment of the name including and after the last dot. The second definition omitted the last dot from the extension. Java-related platforms all exclude the last dot. (One divergent definition in the internal Java NIO method `AbstractFileTypeDetector.getExtension(String)` defines the extension as the part after the *first* dot.) >> >> All examined cases define the extension to be an empty string if it cannot be determined. None of these cases used `null` to represent an indeterminate extension. >> >> Little in the way of specifying behavior for special cases (consisting mainly of file names with one or more leading dots) was found. Most definitions concern themselves only with the last dot and what comes after it and ignore leading dots altogether. A few definitions ignore a leading dot at the zeroth character. The current proposal ignores a dot at character zero. >> >> The behavior of the proposed method for some example cases is as: >> >> . -> >> .. -> >> .a.b -> b >> ...... -> >> .....a -> a >> ....a.b -> b >> ..foo -> foo >> test.rb -> rb >> a/b/d/test.rb -> rb >> .a/b/d/test.rb -> rb >> foo. -> >> test -> >> .profile -> >> .profile.sh -> sh >> ..foo -> foo >> .....foo -> foo >> .vimrc -> >> test. -> >> test.. -> >> test... -> >> foo.tar.gz -> gz >> foo.bar. -> >> image.jpg -> jpg >> music.mp3 -> mp3 >> video.mp4 -> mp4 >> document.txt -> txt >> foo.tar.gz -> gz >> foo.bar. -> > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8057113: Change first sentence; change param name Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2319 From github.com+471021+marschall at openjdk.java.net Sat Mar 13 14:22:38 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sat, 13 Mar 2021 14:22:38 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v8] In-Reply-To: References: Message-ID: > Implement three optimiztations for Reader.read(CharBuffer) > > * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. > * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. > * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. > * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. Philippe Marschall has updated the pull request incrementally with three additional commits since the last revision: - Fix bug in CharArrayReader and add unit test - Clean up unit tests - Revert off-heap code path ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1915/files - new: https://git.openjdk.java.net/jdk/pull/1915/files/fc29f3e6..5fa832b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=06-07 Stats: 134 lines in 5 files changed: 100 ins; 19 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/1915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915 PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+471021+marschall at openjdk.java.net Sat Mar 13 14:28:26 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sat, 13 Mar 2021 14:28:26 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 23:50:30 GMT, Brian Burkhalter wrote: >> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision: >> >> - Replace c-style array declarations >> - Share work buffer between #skip and #read > > test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 34: > >> 32: import org.testng.annotations.Test; >> 33: >> 34: import java.io.*; > > It's generally better not to use a wild card. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+471021+marschall at openjdk.java.net Sat Mar 13 14:28:25 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sat, 13 Mar 2021 14:28:25 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9] In-Reply-To: References: Message-ID: > Implement three optimiztations for Reader.read(CharBuffer) > > * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. > * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. > * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. > * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Merge master - Fix bug in CharArrayReader and add unit test - Clean up unit tests - Revert off-heap code path - Replace c-style array declarations - Share work buffer between #skip and #read - Update copyright year - Implement review comment - Revert StreamDecoder changes - Implement CharArrayReader#read(CharBuffer) - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1915/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=08 Stats: 371 lines in 6 files changed: 361 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1915.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915 PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+471021+marschall at openjdk.java.net Sat Mar 13 14:33:07 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sat, 13 Mar 2021 14:33:07 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 23:52:09 GMT, Brian Burkhalter wrote: >> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision: >> >> - Replace c-style array declarations >> - Share work buffer between #skip and #read > > test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 73: > >> 71: } >> 72: >> 73: buffer.clear(); > > I think `buffer.rewind()` would be more in keeping with the specification verbiage although there will be no practical effect here. Same comment applies below and in the other test `ReadCharBuffer`. `buffer.rewind()` would not work in this specific case as it does not reset the limit. I want to assert the entire buffers content to make sure the method didn't accidentally write where it shouldn't have. Therefore limit needs to be set to capacity. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+471021+marschall at openjdk.java.net Sat Mar 13 14:33:08 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sat, 13 Mar 2021 14:33:08 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7] In-Reply-To: References: Message-ID: <7-5p_NwXkjFzYt2IJquxXXtxSG7IGgVSUrOpJyvg2Sk=.f43bec66-33bc-413c-b2d0-e9d6f8e18454@github.com> On Fri, 19 Feb 2021 07:34:57 GMT, Alan Bateman wrote: >> I think that's what @AlanBateman intended. The `skip()` changes would revert also (I think) but the C-style array changes can stay. Thanks. > > Yes, let's bring it back to just eliminating the intermediate array when the buffer has a backing array. The other case that been examined separated if needed but we can't use the approach proposed in the current PR because it changes the semantics of read when there is a short-read followed by a blocking or exception throwing read. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+471021+marschall at openjdk.java.net Sat Mar 13 14:43:07 2021 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sat, 13 Mar 2021 14:43:07 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) In-Reply-To: References: <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com> Message-ID: On Tue, 16 Feb 2021 23:49:36 GMT, Brian Burkhalter wrote: > I think the implementation changes here look good. I don't know however whether there is enough coverage in the tests. These should verify that the `Reader`, `CharArrayReader`, and `InputStreamReader` implementations of `read(CharBuffer)` are accurate. If there is already sufficient coverage in the tests in `test/jdk/java/io` then that is good enough and nothing need be added. `CharArrayReader` was lacking a test. I added a test which found a bug and fixed the bug. The PR also contains new tests for `Reader` and `InputStreamReader`. They cover on-heap and off-heap cases. Is there a way to get test coverage with JTReg tests? I only found [1] which seems out of date and points to an Oracle internal wiki. [1] https://wiki.openjdk.java.net/display/CodeTools/JCov+FAQ#JCovFAQ-HowdoIuseJCovwithjtreg? ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From bpb at openjdk.java.net Sun Mar 14 08:48:19 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Sun, 14 Mar 2021 08:48:19 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists Message-ID: Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. ------------- Commit messages: - 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists Changes: https://git.openjdk.java.net/jdk/pull/2980/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2980&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241619 Stats: 53 lines in 4 files changed: 47 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2980.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2980/head:pull/2980 PR: https://git.openjdk.java.net/jdk/pull/2980 From alanb at openjdk.java.net Sun Mar 14 13:00:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 14 Mar 2021 13:00:15 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9] In-Reply-To: References: Message-ID: <84oaCizi9wr-vVk-L4OwgmBH8kdLBx5gzy7pejtfko8=.a3d79db9-f147-450e-8d3c-fc491cfa12fe@github.com> On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall wrote: >> Implement three optimiztations for Reader.read(CharBuffer) >> >> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one. >> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`. >> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`. >> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation. > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - Merge master > - Fix bug in CharArrayReader and add unit test > - Clean up unit tests > - Revert off-heap code path > - Replace c-style array declarations > - Share work buffer between #skip and #read > - Update copyright year > - Implement review comment > - Revert StreamDecoder changes > - Implement CharArrayReader#read(CharBuffer) > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0 src/java.base/share/classes/java/io/Reader.java line 205: > 203: target.put(cbuf, 0, nread); > 204: } > 205: return nread; Thanks for bringing this back to just the heap buffer case. This part looks good now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From github.com+7806504+liach at openjdk.java.net Sun Mar 14 17:10:23 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Sun, 14 Mar 2021 17:10:23 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? wrote: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok Are linked lists worse for addition even in cases where addition to array list or deque requires resize and copying? i thought that's the advantage of linked list. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+10835776+stsypanov at openjdk.java.net Sun Mar 14 17:10:23 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sun, 14 Mar 2021 17:10:23 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList Message-ID: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. jdk:tier1 and jdk:tier2 are both ok ------------- Commit messages: - Remove remaining usages of LinkedList in java.base Changes: https://git.openjdk.java.net/jdk/pull/2744/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263561 Stats: 40 lines in 9 files changed: 0 ins; 2 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/2744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744 PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+10835776+stsypanov at openjdk.java.net Sun Mar 14 17:10:23 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sun, 14 Mar 2021 17:10:23 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: On Fri, 26 Feb 2021 15:32:57 GMT, liach wrote: > Are linked lists worse for addition even in cases where addition to array list or deque requires resize and copying? i thought that's the advantage of linked list. As far as I know `LinkedList` is always worse than `ArrayList` and discouraged from being used. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From yyang at openjdk.java.net Sun Mar 14 17:10:24 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Sun, 14 Mar 2021 17:10:24 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> Message-ID: <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com> On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? wrote: > The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. > > jdk:tier1 and jdk:tier2 are both ok src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220: > 218: return Collections.emptyList(); > 219: } > 220: List result = new ArrayList<>(); We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList. Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+7806504+liach at openjdk.java.net Sun Mar 14 17:10:24 2021 From: github.com+7806504+liach at openjdk.java.net (liach) Date: Sun, 14 Mar 2021 17:10:24 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com> Message-ID: On Sun, 14 Mar 2021 14:58:11 GMT, Yi Yang wrote: >> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective. >> >> jdk:tier1 and jdk:tier2 are both ok > > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220: > >> 218: return Collections.emptyList(); >> 219: } >> 220: List result = new ArrayList<>(); > > We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList. > > Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values. If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr) ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+10835776+stsypanov at openjdk.java.net Sun Mar 14 17:21:11 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sun, 14 Mar 2021 17:21:11 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com> Message-ID: <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com> On Sun, 14 Mar 2021 15:02:03 GMT, liach wrote: >> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220: >> >>> 218: return Collections.emptyList(); >>> 219: } >>> 220: List result = new ArrayList<>(); >> >> We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList. >> >> Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values. > > If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr) Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From alanb at openjdk.java.net Sun Mar 14 17:22:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 14 Mar 2021 17:22:07 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 22:38:05 GMT, Brian Burkhalter wrote: > Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. > > A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. > > The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. src/java.base/share/classes/java/nio/channels/FileChannel.java line 277: > 275: * StandardOpenOption#CREATE_NEW CREATE_NEW} option is specified > 276: * and the file is being opened for writing > 277: * (optional specific exception) This may be the first usage of optional specific exceptions in the java.nio.channels API docs. It's okay to do this but it will require linking to the java.nio.file package description where this is defined. You'll also need to import the exception or use the fully qualified class file here. Probably best to replace "if" with "If" to be consistent with the other exception messages here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From alanb at openjdk.java.net Sun Mar 14 17:29:06 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 14 Mar 2021 17:29:06 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com> <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com> Message-ID: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com> On Sun, 14 Mar 2021 17:18:11 GMT, ?????? ??????? wrote: >> If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr) > > Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes. Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From github.com+10835776+stsypanov at openjdk.java.net Sun Mar 14 18:24:17 2021 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sun, 14 Mar 2021 18:24:17 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com> <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com> <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com> Message-ID: On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman wrote: >> Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes. > > Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here. @AlanBateman so is it ok to keep `ArrayLists`? ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From alanb at openjdk.java.net Mon Mar 15 06:59:07 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 15 Mar 2021 06:59:07 GMT Subject: RFR: 8263561: Re-examine uses of LinkedList In-Reply-To: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com> References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com> <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com> <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com> <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com> Message-ID: On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman wrote: >> Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes. > > Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here. > @AlanBateman so is it ok to keep `ArrayLists`? One thing to look out for is usages of 2-arg add method that inserts at a specific position. This shouldn't be a concern in URLClassPath.closeLoaders (assuming this is this usage where the question arises). ------------- PR: https://git.openjdk.java.net/jdk/pull/2744 From jboes at openjdk.java.net Mon Mar 15 12:55:11 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 15 Mar 2021 12:55:11 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 > > @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? @turbanoff Given that this PR has been lingering for a while, you could drop the change in `X509CertPath.java` for now and integrate the remaining changes. I'm happy to sponsor in that case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From alanb at openjdk.java.net Mon Mar 15 13:16:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 15 Mar 2021 13:16:09 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced In-Reply-To: References: Message-ID: <421fXwZXZYOoLSoc9d8CegQ3wWY0DxpgvB7xLiTPIK0=.c5123e58-5264-4d58-a683-673af36d8451@github.com> On Tue, 9 Mar 2021 22:20:52 GMT, Brian Burkhalter wrote: > Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. > > The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) > > In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. > > A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. > > Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. src/java.base/share/classes/java/nio/MappedByteBuffer.java line 396: > 394: */ > 395: @Override > 396: public abstract MappedByteBuffer slice(int index, int length); The updates to make use covariant returns is good but I'm not sure about the proposal "API note"s. I should drop "API note" because it's really spec text. Also I think it would be simpler to drop the "A similar consideration ..." to avoid confusing the reader. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From github.com+741251+turbanoff at openjdk.java.net Mon Mar 15 14:50:24 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 15 Mar 2021 14:50:24 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy [v13] In-Reply-To: References: Message-ID: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy drop changes in X509CertPath ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1853/files - new: https://git.openjdk.java.net/jdk/pull/1853/files/1b30471d..96920ee6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11-12 Stats: 25 lines in 1 file changed: 22 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1853.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853 PR: https://git.openjdk.java.net/jdk/pull/1853 From bpb at openjdk.java.net Mon Mar 15 17:27:11 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 15 Mar 2021 17:27:11 GMT Subject: Integrated: 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test In-Reply-To: References: Message-ID: On Fri, 19 Feb 2021 00:34:24 GMT, Brian Burkhalter wrote: > This change proposes to increase the number of retries of `FlushViewOfFile` in the Windows native implementation of `MappedByteBuffer.force()`, and to catch any exception thrown by the native `force()` and rethrow an `UncheckedIOException` with cause set to the intercepted exception. A sentence is added to the specification of `MappedByteBuffer.force()` regarding unspecified errors. The test from the issue description is revised to fail if `force()` throws an exception which is not an `UncheckedIOException`, or if it is an `UncheckedIOException` whose message indicates it was thrown by the Windows native implementation of `force()`. This pull request has now been integrated. Changeset: 46d78f0d Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/46d78f0d Stats: 97 lines in 5 files changed: 92 ins; 0 del; 5 mod 6539707: (fc) MappedByteBuffer.force() method throws an IOException in a very simple test Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2636 From bpb at openjdk.java.net Mon Mar 15 17:44:08 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 15 Mar 2021 17:44:08 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists In-Reply-To: References: Message-ID: On Sun, 14 Mar 2021 17:19:06 GMT, Alan Bateman wrote: >> Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. >> >> A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. >> >> The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 277: > >> 275: * StandardOpenOption#CREATE_NEW CREATE_NEW} option is specified >> 276: * and the file is being opened for writing >> 277: * (optional specific exception) > > This may be the first usage of optional specific exceptions in the java.nio.channels API docs. It's okay to do this but it will require linking to the java.nio.file package description where this is defined. You'll also need to import the exception or use the fully qualified class file here. Probably best to replace "if" with "If" to be consistent with the other exception messages here. Thanks for adding the `nio` label. I had mentioned the package description already and will update that. There is not much consistency in whether the first letter of the `@throws` verbiage is upper case. ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From jboes at openjdk.java.net Mon Mar 15 18:52:17 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 15 Mar 2021 18:52:17 GMT Subject: RFR: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com> Message-ID: <4Bae_Uh8Zakn4cnmbXkUcV9xRTus1hgHCEPVthHuEyc=.fb959963-ff7a-4067-b888-e178d9f70e91@github.com> On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov wrote: >> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed? >> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422 >> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746 > > @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)? @turbanoff Tier 1-3 still all clear. If you /integrate, I will sponsor this tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From bpb at openjdk.java.net Mon Mar 15 19:02:32 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 15 Mar 2021 19:02:32 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists [v2] In-Reply-To: References: Message-ID: > Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. > > A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. > > The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8241619: change "if" to "IF"; link optional specific exception doc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2980/files - new: https://git.openjdk.java.net/jdk/pull/2980/files/d9417bde..324670e9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2980&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2980&range=00-01 Stats: 25 lines in 6 files changed: 6 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/2980.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2980/head:pull/2980 PR: https://git.openjdk.java.net/jdk/pull/2980 From bpb at openjdk.java.net Mon Mar 15 20:11:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 15 Mar 2021 20:11:29 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v2] In-Reply-To: References: Message-ID: > Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. > > The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) > > In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. > > A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. > > Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4833719: Remove @apiNotes and "A similar consideration" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2902/files - new: https://git.openjdk.java.net/jdk/pull/2902/files/dec7dc93..eaeee3c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2902/head:pull/2902 PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Mon Mar 15 20:51:29 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 15 Mar 2021 20:51:29 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v3] In-Reply-To: References: Message-ID: > Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. > > The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) > > In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. > > A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. > > Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4833719: Corrected faux pas in the slice(int,int) spec ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2902/files - new: https://git.openjdk.java.net/jdk/pull/2902/files/eaeee3c3..dfe6364d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2902/head:pull/2902 PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Mon Mar 15 21:27:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 15 Mar 2021 21:27:25 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: References: Message-ID: > Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. > > The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) > > In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. > > A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. > > Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4833719: Corrected faux pas in correcting faux pas ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2902/files - new: https://git.openjdk.java.net/jdk/pull/2902/files/dfe6364d..6bd09bf9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2902/head:pull/2902 PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Mon Mar 15 21:42:11 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 15 Mar 2021 21:42:11 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: <0D4TrhDG9TocjIyXQspgWkA2gSJQWnadRRd3KSRwBv8=.b5ad1781-413a-44b1-83d5-353e4f009f8f@github.com> References: <0D4TrhDG9TocjIyXQspgWkA2gSJQWnadRRd3KSRwBv8=.b5ad1781-413a-44b1-83d5-353e4f009f8f@github.com> Message-ID: On Wed, 10 Mar 2021 10:12:19 GMT, Andrew Dinn wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 4833719: Corrected faux pas in correcting faux pas > > This looks good. CSR filed: https://bugs.openjdk.java.net/browse/JDK-8263620. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From adinn at openjdk.java.net Tue Mar 16 10:04:15 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 16 Mar 2021 10:04:15 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: References: Message-ID: <7SHUJuZJqDzuqF7w-B-fce7R_W5PtUf2AZo_-bpPiSc=.6d54c9b3-89cb-48b4-83fe-aaaa1f06bc78@github.com> On Mon, 15 Mar 2021 21:27:25 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. >> >> The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) >> >> In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. >> >> A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. >> >> Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 4833719: Corrected faux pas in correcting faux pas src/java.base/share/classes/java/nio/MappedByteBuffer.java line 377: > 375: * {@code force()} on the returned buffer, will only act on the sub-range > 376: * of this buffer that the returned buffer represents, namely > 377: * {@code [position(),limit()]}. Is the closing bracket on this interval meant to be ']' or ')'? i.e. is the interval inclusive of exclusive of the value at the index returned by limit()? ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From github.com+741251+turbanoff at openjdk.java.net Tue Mar 16 10:13:11 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 16 Mar 2021 10:13:11 GMT Subject: Integrated: 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy In-Reply-To: References: Message-ID: On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov wrote: > 8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy This pull request has now been integrated. Changeset: 68deb24b Author: Andrey Turbanov Committer: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/68deb24b Stats: 105 lines in 7 files changed: 3 ins; 78 del; 24 mod 8080272: Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy Reviewed-by: mcimadamore, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/1853 From alanb at openjdk.java.net Tue Mar 16 14:12:28 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 16 Mar 2021 14:12:28 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: <7SHUJuZJqDzuqF7w-B-fce7R_W5PtUf2AZo_-bpPiSc=.6d54c9b3-89cb-48b4-83fe-aaaa1f06bc78@github.com> References: <7SHUJuZJqDzuqF7w-B-fce7R_W5PtUf2AZo_-bpPiSc=.6d54c9b3-89cb-48b4-83fe-aaaa1f06bc78@github.com> Message-ID: On Tue, 16 Mar 2021 10:01:22 GMT, Andrew Dinn wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 4833719: Corrected faux pas in correcting faux pas > > src/java.base/share/classes/java/nio/MappedByteBuffer.java line 377: > >> 375: * {@code force()} on the returned buffer, will only act on the sub-range >> 376: * of this buffer that the returned buffer represents, namely >> 377: * {@code [position(),limit()]}. > > Is the closing bracket on this interval meant to be ']' or ')'? i.e. is the interval inclusive of exclusive of the value at the index returned by limit()? The no-arg force method used to write back the entire buffer content [0, capacity]. It has been changed to use the limit, meaning [0, limit]. I don't recall this being an intentional change. I'm asking now because the change in this PR will specify the new behavior rather than the long standing behavior. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From alanb at openjdk.java.net Tue Mar 16 14:13:12 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 16 Mar 2021 14:13:12 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists [v2] In-Reply-To: References: Message-ID: On Mon, 15 Mar 2021 19:02:32 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. >> >> A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. >> >> The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8241619: change "if" to "IF"; link optional specific exception doc src/java.base/share/classes/java/nio/file/spi/package-info.java line 36: > 34: * java.lang.NullPointerException NullPointerException} to be thrown. In some > 35: * cases methods which are specified to throw an {@code IOException} may throw > 36: * a more precise optional The terminology in the reference section is "optional specific exception" so it would be more consistent to continue with "specific" rather than switching to "precise" here. I'm in two minds about adding this to the java.nio.channels package description as it's only applicable to the static open methods defined by FileChannel and AsynchronousFileChannel. ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From adinn at openjdk.java.net Tue Mar 16 14:30:10 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 16 Mar 2021 14:30:10 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: References: <7SHUJuZJqDzuqF7w-B-fce7R_W5PtUf2AZo_-bpPiSc=.6d54c9b3-89cb-48b4-83fe-aaaa1f06bc78@github.com> Message-ID: On Tue, 16 Mar 2021 13:44:57 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/nio/MappedByteBuffer.java line 377: >> >>> 375: * {@code force()} on the returned buffer, will only act on the sub-range >>> 376: * of this buffer that the returned buffer represents, namely >>> 377: * {@code [position(),limit()]}. >> >> Is the closing bracket on this interval meant to be ']' or ')'? i.e. is the interval inclusive of exclusive of the value at the index returned by limit()? > > The no-arg force method used to write back the entire buffer content [0, capacity]. It has been changed to use the limit, meaning [0, limit]. I don't recall this being an intentional change. I'm asking now because the change in this PR will specify the new behavior rather than the long standing behavior. @AlanBateman Hmm, I think that's a different issue to my comment. I asked my question above because the correction Brian made when documenting slice(int index, int length) employed a half-closed interval with an exclusive right bound for the interval [index,index+length) and I merely felt that the same should apply here in the documentation of slice() [position(),limit()) I'm not sure I am in a position to provide the right answer to your question but I'll note that in the same pedantic vein the intervals you mention should be similarly semi-closed [0, capacity) and [0, limit) The byte at index limit/capacity is not necessarily flushed (modulo page roundings). As to what might be a correct answer: > The no-arg force method used to write back the entire buffer content [0, capacity]. It has been changed to use the limit, meaning [0, limit]. I don't recall this being an intentional change. I believe this was done intentionally when I introduced the force(int,int) variant and re-implemented the noargs variant to indirect to it. I cannot recall why it changed from capacity to limit though. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From alanb at openjdk.java.net Tue Mar 16 14:42:08 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 16 Mar 2021 14:42:08 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: References: <7SHUJuZJqDzuqF7w-B-fce7R_W5PtUf2AZo_-bpPiSc=.6d54c9b3-89cb-48b4-83fe-aaaa1f06bc78@github.com> Message-ID: On Tue, 16 Mar 2021 14:26:47 GMT, Andrew Dinn wrote: >> The no-arg force method used to write back the entire buffer content [0, capacity]. It has been changed to use the limit, meaning [0, limit]. I don't recall this being an intentional change. I'm asking now because the change in this PR will specify the new behavior rather than the long standing behavior. > > @AlanBateman Hmm, I think that's a different issue to my comment. > > I asked my question above because the correction Brian made when documenting slice(int index, int length) employed a half-closed interval with an exclusive right bound for the interval > > [index,index+length) > > and I merely felt that the same should apply here in the documentation of slice() > > [position(),limit()) > > I'm not sure I am in a position to provide the right answer to your question but I'll note that in the same pedantic vein the intervals you mention should be similarly semi-closed > > [0, capacity) > > and > > [0, limit) > > The byte at index limit/capacity is not necessarily flushed (modulo page roundings). > > As to what might be a correct answer: > >> The no-arg force method used to write back the entire buffer content [0, capacity]. It has been changed to use the limit, meaning [0, limit]. I don't recall this being an intentional change. > > I believe this was done intentionally when I introduced the force(int,int) variant and re-implemented the noargs variant to indirect to it. I cannot recall why it changed from capacity to limit though. @adinn My comment wasn't to you, it's a concern that the no-arg force method has changed and the new behavior is proposed to be specified by this PR. I need to re-read the mails as it may be that this will need to be restored to use the capacity. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Tue Mar 16 15:40:07 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 16 Mar 2021 15:40:07 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: References: <7SHUJuZJqDzuqF7w-B-fce7R_W5PtUf2AZo_-bpPiSc=.6d54c9b3-89cb-48b4-83fe-aaaa1f06bc78@github.com> Message-ID: On Tue, 16 Mar 2021 14:39:19 GMT, Alan Bateman wrote: >> @AlanBateman Hmm, I think that's a different issue to my comment. >> >> I asked my question above because the correction Brian made when documenting slice(int index, int length) employed a half-closed interval with an exclusive right bound for the interval >> >> [index,index+length) >> >> and I merely felt that the same should apply here in the documentation of slice() >> >> [position(),limit()) >> >> I'm not sure I am in a position to provide the right answer to your question but I'll note that in the same pedantic vein the intervals you mention should be similarly semi-closed >> >> [0, capacity) >> >> and >> >> [0, limit) >> >> The byte at index limit/capacity is not necessarily flushed (modulo page roundings). >> >> As to what might be a correct answer: >> >>> The no-arg force method used to write back the entire buffer content [0, capacity]. It has been changed to use the limit, meaning [0, limit]. I don't recall this being an intentional change. >> >> I believe this was done intentionally when I introduced the force(int,int) variant and re-implemented the noargs variant to indirect to it. I cannot recall why it changed from capacity to limit though. > > @adinn My comment wasn't to you, it's a concern that the no-arg force method has changed and the new behavior is proposed to be specified by this PR. I need to re-read the mails as it may be that this will need to be restored to use the capacity. The right hand limit should in all cases be open so the current no-arg doc is wrong. As for `force()` changing from `[0,capacity())` to `[0,limit())`, I don't know exactly why that happened or when but it definitely changed since Java 8. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Tue Mar 16 18:35:26 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 16 Mar 2021 18:35:26 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists [v3] In-Reply-To: References: Message-ID: <1AfZzx-R3POvCR2Lkdlr40_ZBXtVIpsqWeFnz1RU8iI=.1c433ed8-111c-455f-b5ff-3dfd38a0fdd5@github.com> > Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. > > A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. > > The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8241619: package docs - remove java.nio.channels change, update java.nio.file.spi change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2980/files - new: https://git.openjdk.java.net/jdk/pull/2980/files/324670e9..58c33e82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2980&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2980&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2980.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2980/head:pull/2980 PR: https://git.openjdk.java.net/jdk/pull/2980 From bpb at openjdk.java.net Tue Mar 16 18:35:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 16 Mar 2021 18:35:27 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists [v2] In-Reply-To: References: Message-ID: <1jqcEp3jqoU_y3kMc_1hinEIY3sdBEs7emqtuBY2-hk=.5f1b9789-7df4-4e7b-bae0-a3abe1ab8c5a@github.com> On Tue, 16 Mar 2021 13:51:24 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8241619: change "if" to "IF"; link optional specific exception doc > > src/java.base/share/classes/java/nio/file/spi/package-info.java line 36: > >> 34: * java.lang.NullPointerException NullPointerException} to be thrown. In some >> 35: * cases methods which are specified to throw an {@code IOException} may throw >> 36: * a more precise optional > > The terminology in the reference section is "optional specific exception" so it would be more consistent to continue with "specific" rather than switching to "precise" here. I'm in two minds about adding this to the java.nio.channels package description as it's only applicable to the static open methods defined by FileChannel and AsynchronousFileChannel. Changed "precise" to "specific" and removed update to `java.nio.channels` package doc. ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From jai.forums2013 at gmail.com Wed Mar 17 03:21:40 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 17 Mar 2021 08:51:40 +0530 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? Message-ID: Please consider this trivial code: import java.io.*; import java.nio.file.*; public class FileTest { ??? public static void main(final String[] args) throws Exception { ??????? System.getProperties().list(System.out); ??????? final File f = new File("NUL:"); ??????? try (final InputStream fis = Files.newInputStream(f.toPath())) { ?? ??? ??? ??? ?int numBytes = 0; ?? ??? ??? ??? ?while (fis.read() != -1) { ?? ??? ??? ??? ??? ?System.out.println("Files.newInputStream - Read a byte from " + f); ?? ??? ??? ??? ??? ?numBytes++; ?? ??? ??? ??? ?} ?? ??? ??? ??? ?System.out.println("Files.newInputStream - Done reading " + numBytes + " bytes from " + f); ?? ??? ?} ?? ?} } The code tries to read from NUL: on a Windows setup. This code runs into the following exception on Windows when the java.io.File#toPath() gets invoked: Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <:> at index 3: NUL: ??? at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) ??? at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) ??? at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) ??? at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) ??? at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) ??? at java.base/java.io.File.toPath(File.java:2316) ??? at FileTest.main(FileTest.java:18) So it looks like java.io.File.toPath() on Windows isn't able to recognize the null device construct? Just to make sure this issue resides only this specific API implementation, I switched the above code to use new FileInputStream(f) as follows and that works as expected - reads 0 bytes and completes successfully. So the NUL: construct is indeed understood by the other APIs. public class FileTest { ??? public static void main(final String[] args) throws Exception { ??????? System.getProperties().list(System.out); ??????? final File f = new File("NUL:"); ??????? try (final FileInputStream fis = new FileInputStream(f)) { ??? ??? ??? ??? int numBytes = 0; ??? ??? ??? ??? while (fis.read() != -1) { ??? ??? ??? ??? ??? System.out.println("FileInputStream() - Read a byte from " + f); ??? ??? ??? ??? ??? numBytes++; ??? ??? ??? ??? } ??? ??? ??? ??? System.out.println("FileInputStream() - Done reading " + numBytes + " bytes from " + f); ??? ??? } ??? } } Output: FileInputStream() - Done reading 0 bytes from NUL: Test results are from latest Java 16 release on a Windows setup. -Jaikiran From jai.forums2013 at gmail.com Wed Mar 17 03:26:52 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 17 Mar 2021 08:56:52 +0530 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: References: Message-ID: <65f61d07-df6a-56c0-7f5b-ca6cd8da85cf@gmail.com> On 17/03/21 8:51 am, Jaikiran Pai wrote: > > Test results are from latest Java 16 release on a Windows setup. Just gave a quick try against Java 8 (java.version=1.8.0_252) and it fails on that version too with the same error: Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <:> at index 3: NUL: ??? at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) ??? at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) ??? at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) ??? at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94) ??? at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255) ??? at java.io.File.toPath(File.java:2234) ??? at FileTest.main(FileTest.java:18) -Jaikiran From david.holmes at oracle.com Wed Mar 17 07:13:53 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Mar 2021 17:13:53 +1000 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: References: Message-ID: <247e84e9-63b1-c8ab-1e15-1f7dc1cc69df@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8022671 Cheers, David On 17/03/2021 1:21 pm, Jaikiran Pai wrote: > Please consider this trivial code: > > import java.io.*; > import java.nio.file.*; > > public class FileTest { > ??? public static void main(final String[] args) throws Exception { > ??????? System.getProperties().list(System.out); > ??????? final File f = new File("NUL:"); > ??????? try (final InputStream fis = Files.newInputStream(f.toPath())) { > ?? ??? ??? ??? ?int numBytes = 0; > ?? ??? ??? ??? ?while (fis.read() != -1) { > ?? ??? ??? ??? ??? ?System.out.println("Files.newInputStream - Read a > byte from " + f); > ?? ??? ??? ??? ??? ?numBytes++; > ?? ??? ??? ??? ?} > ?? ??? ??? ??? ?System.out.println("Files.newInputStream - Done reading > " + numBytes + " bytes from " + f); > ?? ??? ?} > ?? ?} > } > > > The code tries to read from NUL: on a Windows setup. This code runs into > the following exception on Windows when the java.io.File#toPath() gets > invoked: > > > Exception in thread "main" java.nio.file.InvalidPathException: Illegal > char <:> at index 3: NUL: > ??? at > java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > > ??? at > java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > ??? at > java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > ??? at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > ??? at > java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) > ??? at java.base/java.io.File.toPath(File.java:2316) > ??? at FileTest.main(FileTest.java:18) > > > So it looks like java.io.File.toPath() on Windows isn't able to > recognize the null device construct? > > Just to make sure this issue resides only this specific API > implementation, I switched the above code to use new FileInputStream(f) > as follows and that works as expected - reads 0 bytes and completes > successfully. So the NUL: construct is indeed understood by the other APIs. > > > public class FileTest { > ??? public static void main(final String[] args) throws Exception { > ??????? System.getProperties().list(System.out); > ??????? final File f = new File("NUL:"); > ??????? try (final FileInputStream fis = new FileInputStream(f)) { > ??? ??? ??? ??? int numBytes = 0; > ??? ??? ??? ??? while (fis.read() != -1) { > ??? ??? ??? ??? ??? System.out.println("FileInputStream() - Read a byte > from " + f); > ??? ??? ??? ??? ??? numBytes++; > ??? ??? ??? ??? } > ??? ??? ??? ??? System.out.println("FileInputStream() - Done reading " > + numBytes + " bytes from " + f); > ??? ??? } > ??? } > } > > Output: > > FileInputStream() - Done reading 0 bytes from NUL: > > Test results are from latest Java 16 release on a Windows setup. > > -Jaikiran > From Alan.Bateman at oracle.com Wed Mar 17 07:56:58 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Mar 2021 07:56:58 +0000 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: References: Message-ID: On 17/03/2021 03:21, Jaikiran Pai wrote: > : > > > The code tries to read from NUL: on a Windows setup. This code runs > into the following exception on Windows when the java.io.File#toPath() > gets invoked: > > > Exception in thread "main" java.nio.file.InvalidPathException: Illegal > char <:> at index 3: NUL: > ??? at > java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > ??? at > java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > ??? at > java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > ??? at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > ??? at > java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) > ??? at java.base/java.io.File.toPath(File.java:2316) > ??? at FileTest.main(FileTest.java:18) > > > So it looks like java.io.File.toPath() on Windows isn't able to > recognize the null device construct? Special devices, esp. those historical devices from the DOS era, are very problematic. NUL is somewhat benign compared to the other and you use "NUL" (not "NUL:") then should work as you expect. Changing the path parser to allow ":" in places other than after drive letters is a slippery slope as it brings all a lot of the issues that plagued the older code. -Alan From jai.forums2013 at gmail.com Wed Mar 17 08:21:14 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 17 Mar 2021 13:51:14 +0530 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: References: Message-ID: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com> On 17/03/21 1:26 pm, Alan Bateman wrote: > On 17/03/2021 03:21, Jaikiran Pai wrote: >> : >> >> >> The code tries to read from NUL: on a Windows setup. This code runs >> into the following exception on Windows when the >> java.io.File#toPath() gets invoked: >> >> >> Exception in thread "main" java.nio.file.InvalidPathException: >> Illegal char <:> at index 3: NUL: >> ??? at >> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) >> ??? at >> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) >> ??? at >> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) >> ??? at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) >> ??? at >> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230) >> ??? at java.base/java.io.File.toPath(File.java:2316) >> ??? at FileTest.main(FileTest.java:18) >> >> >> So it looks like java.io.File.toPath() on Windows isn't able to >> recognize the null device construct? > > Special devices, esp. those historical devices from the DOS era, are > very problematic. > > NUL is somewhat benign compared to the other and you use "NUL" (not > "NUL:") then should work as you expect. Thank you David and Alan. I can confirm that using "NUL" or "nul" work fine in the above code, with the FileInputStream/FileOutputStream constructors as well as Files.newInputStream(f.toPath()) and Files.newOutputStream(f.toPath()). > Changing the path parser to allow ":" in places other than after drive > letters is a slippery slope as it brings all a lot of the issues that > plagued the older code. Understood. -Jaikiran From Alan.Bateman at oracle.com Wed Mar 17 09:15:21 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Mar 2021 09:15:21 +0000 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com> References: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com> Message-ID: <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com> On 17/03/2021 08:21, Jaikiran Pai wrote: > : > > I can confirm that using "NUL" or "nul" work fine in the above code, I don't know the context for your question but just to mention InputStream.nullInputStream() or Reader.nullReader() may be useful if you have something that wants to read from a null stream. -Alan. From jai.forums2013 at gmail.com Wed Mar 17 09:40:04 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 17 Mar 2021 15:10:04 +0530 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com> References: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com> <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com> Message-ID: <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com> Hello Alan, On 17/03/21 2:45 pm, Alan Bateman wrote: > On 17/03/2021 08:21, Jaikiran Pai wrote: >> : >> >> I can confirm that using "NUL" or "nul" work fine in the above code, > > I don't know the context for your question A while back Apache Ant switched to using the Files.newInputStream/Files.newOutputStream construct as a replacement for the FileInputStream and FileOutputStream constructors[1]. That commit seems to have introduced an regression in Ant as noted here[2]. It appears that users of Ant were using "nul" (and even "nul:") as destination file to have Ant write the data to that destination. Internally Ant constructs an instance of java.io.File from the user provided path string ("nul" or "nul:" in this case) and constructs a OutputStream out of it. Previously (before we made that commit in Ant), it would be using the FileOutputStream constructor (and would succeed) and now it uses the Files.newOuputStream(...) which expects a Path instance and this where our usage of java.io.File.toPath() ran into the issue I note in this mail, when I started investigating this. I didn't mention this context in my mail because the error noted in those user reports is surprisingly a bit different than what I have seen in my experiments on Windows and I don't think I have so far narrowed it down to a JDK issue (if any). In their case, it appears the call went past the issue we are discussing this mail and instead failed later with something like: java.nio.file.FileSystemException: E:\nul: Incorrect function. ??????? at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) ??????? at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) ??????? at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) ??????? at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230) ??????? at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434) ??????? at java.nio.file.Files.newOutputStream(Files.java:216) I'm not yet sure how they managed to get to that stage and am waiting to see if they can provide us with a reproducible build file to reproduce this. > but just to mention InputStream.nullInputStream() or > Reader.nullReader() may be useful if you have something that wants to > read from a null stream. We have had a recent discussion in Ant dev mailing list[3] to introduce such a construct in some of our Ant tasks where users can tell us that they want the output/error output discarded (that's what they are using /dev/null and "nul:" for). That will prevent all these platform specific usages of null device representations. Internally, in the implementation, we will use the APIs like the one you note and avoid having to deal with null devices. [1] https://github.com/apache/ant/commit/af74d1f6b882cef5f4167d972638ad886d12d58c [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62330 [3] https://www.mail-archive.com/dev at ant.apache.org/msg48730.html -Jaikiran From jai.forums2013 at gmail.com Wed Mar 17 09:46:31 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 17 Mar 2021 15:16:31 +0530 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com> References: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com> <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com> <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com> Message-ID: <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com> On 17/03/21 3:10 pm, Jaikiran Pai wrote: > Hello Alan, > > On 17/03/21 2:45 pm, Alan Bateman wrote: >> On 17/03/2021 08:21, Jaikiran Pai wrote: >>> : >>> >>> I can confirm that using "NUL" or "nul" work fine in the above code, >> >> I don't know the context for your question > > A while back Apache Ant switched to using the > Files.newInputStream/Files.newOutputStream construct as a replacement > for the FileInputStream and FileOutputStream constructors[1]. That > commit seems to have introduced an regression in Ant as noted here[2]. > It appears that users of Ant were using "nul" (and even "nul:") as > destination file to have Ant write the data to that destination. > Internally Ant constructs an instance of java.io.File from the user > provided path string ("nul" or "nul:" in this case) and constructs a > OutputStream out of it. Previously (before we made that commit in > Ant), it would be using the FileOutputStream constructor (and would > succeed) and now it uses the Files.newOuputStream(...) which expects a > Path instance and this where our usage of java.io.File.toPath() ran > into the issue I note in this mail, when I started investigating this. > > I didn't mention this context in my mail because the error noted in > those user reports is surprisingly a bit different than what I have > seen in my experiments on Windows and I don't think I have so far > narrowed it down to a JDK issue (if any). In their case, it appears > the call went past the issue we are discussing this mail and instead > failed later with something like: > > java.nio.file.FileSystemException: E:\nul: Incorrect function. > ??????? at > sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86) > ??????? at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97) > ??????? at > sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102) > ??????? at > sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230) > ??????? at > java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434) > ??????? at java.nio.file.Files.newOutputStream(Files.java:216) > > > I'm not yet sure how they managed to get to that stage and am waiting > to see if they can provide us with a reproducible build file to > reproduce this. > FWIW - that bug report states that they ran into this even when using "nul" and not just "nul:". So there might be something more going on here and am just waiting to see if they can provide us a build file to reproduce this issue. -Jaikiran From bpb at openjdk.java.net Wed Mar 17 17:00:00 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 17 Mar 2021 17:00:00 GMT Subject: RFR: 8263742: (bf) MappedByteBuffer.force() should use the capacity as its upper bound Message-ID: Prior to JDK 15, the method `java.nio.MappedByteBuffer.force()` wrote back the entire contents of the buffer, i.e., the half-open range `[0,capacity())`. In JDK 15 the upper bound of the write-back changed from `capacity()` to `limit()`. The change was inadvertent through a chain of fixes outlined in the description of the associated issue. This request is to change back to the previous behavior and use the capacity instead of the limit as the upper bound of the write-back. ------------- Commit messages: - 8263742: (bf) MappedByteBuffer.force() should use the capacity as its upper bound Changes: https://git.openjdk.java.net/jdk/pull/3052/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3052&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263742 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3052.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3052/head:pull/3052 PR: https://git.openjdk.java.net/jdk/pull/3052 From adinn at openjdk.java.net Wed Mar 17 17:12:49 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Wed, 17 Mar 2021 17:12:49 GMT Subject: RFR: 8263742: (bf) MappedByteBuffer.force() should use the capacity as its upper bound In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 16:49:27 GMT, Brian Burkhalter wrote: > Prior to JDK 15, the method `java.nio.MappedByteBuffer.force()` wrote back the entire contents of the buffer, i.e., the half-open range `[0,capacity())`. In JDK 15 the upper bound of the write-back changed from `capacity()` to `limit()`. The change was inadvertent through a chain of fixes outlined in the description of the associated issue. This request is to change back to the previous behavior and use the capacity instead of the limit as the upper bound of the write-back. Looks good. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3052 From alanb at openjdk.java.net Thu Mar 18 08:30:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Mar 2021 08:30:49 GMT Subject: RFR: 8263742: (bf) MappedByteBuffer.force() should use the capacity as its upper bound In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 16:49:27 GMT, Brian Burkhalter wrote: > Prior to JDK 15, the method `java.nio.MappedByteBuffer.force()` wrote back the entire contents of the buffer, i.e., the half-open range `[0,capacity())`. In JDK 15 the upper bound of the write-back changed from `capacity()` to `limit()`. The change was inadvertent through a chain of fixes outlined in the description of the associated issue. This request is to change back to the previous behavior and use the capacity instead of the limit as the upper bound of the write-back. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3052 From alanb at openjdk.java.net Thu Mar 18 08:32:48 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Mar 2021 08:32:48 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: References: <7SHUJuZJqDzuqF7w-B-fce7R_W5PtUf2AZo_-bpPiSc=.6d54c9b3-89cb-48b4-83fe-aaaa1f06bc78@github.com> Message-ID: On Tue, 16 Mar 2021 15:37:20 GMT, Brian Burkhalter wrote: >> @adinn My comment wasn't to you, it's a concern that the no-arg force method has changed and the new behavior is proposed to be specified by this PR. I need to re-read the mails as it may be that this will need to be restored to use the capacity. > > The right hand limit should in all cases be open so the current no-arg doc is wrong. > > As for `force()` changing from `[0,capacity())` to `[0,limit())`, I don't know exactly why that happened or when but it definitely changed since Java 8. np, and I assume we'll continue this PR assuming JDK-8263742 will be integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From alanb at openjdk.java.net Thu Mar 18 08:55:49 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 18 Mar 2021 08:55:49 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 22:38:05 GMT, Brian Burkhalter wrote: > Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. > > A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. > > The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. Are you planning to link the use of "optional specific exception" in FileChannel to the section in the java.nio.file package description? Also if we are adding optional specific exceptions to FileChannel.open then we'll have to do the same for AsynchronousFileChannel.open. ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From bpb at openjdk.java.net Thu Mar 18 15:46:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Mar 2021 15:46:41 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v4] In-Reply-To: References: <7SHUJuZJqDzuqF7w-B-fce7R_W5PtUf2AZo_-bpPiSc=.6d54c9b3-89cb-48b4-83fe-aaaa1f06bc78@github.com> Message-ID: On Thu, 18 Mar 2021 08:30:16 GMT, Alan Bateman wrote: >> The right hand limit should in all cases be open so the current no-arg doc is wrong. >> >> As for `force()` changing from `[0,capacity())` to `[0,limit())`, I don't know exactly why that happened or when but it definitely changed since Java 8. > > np, and I assume we'll continue this PR assuming JDK-8263742 will be integrated. The change for JDK-8263742 will be integrated after its yet to be filed CSR is approved. The branch of this PR will need to be rebased. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Thu Mar 18 17:31:41 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Mar 2021 17:31:41 GMT Subject: RFR: 8263742: (bf) MappedByteBuffer.force() should use the capacity as its upper bound In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 08:28:11 GMT, Alan Bateman wrote: >> Prior to JDK 15, the method `java.nio.MappedByteBuffer.force()` wrote back the entire contents of the buffer, i.e., the half-open range `[0,capacity())`. In JDK 15 the upper bound of the write-back changed from `capacity()` to `limit()`. The change was inadvertent through a chain of fixes outlined in the description of the associated issue. This request is to change back to the previous behavior and use the capacity instead of the limit as the upper bound of the write-back. > > Marked as reviewed by alanb (Reviewer). CSR filed: https://bugs.openjdk.java.net/browse/JDK-8263826 ------------- PR: https://git.openjdk.java.net/jdk/pull/3052 From bpb at openjdk.java.net Thu Mar 18 21:15:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Mar 2021 21:15:39 GMT Subject: Integrated: 8263742: (bf) MappedByteBuffer.force() should use the capacity as its upper bound In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 16:49:27 GMT, Brian Burkhalter wrote: > Prior to JDK 15, the method `java.nio.MappedByteBuffer.force()` wrote back the entire contents of the buffer, i.e., the half-open range `[0,capacity())`. In JDK 15 the upper bound of the write-back changed from `capacity()` to `limit()`. The change was inadvertent through a chain of fixes outlined in the description of the associated issue. This request is to change back to the previous behavior and use the capacity instead of the limit as the upper bound of the write-back. This pull request has now been integrated. Changeset: fa0f1614 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/fa0f1614 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod 8263742: (bf) MappedByteBuffer.force() should use the capacity as its upper bound Reviewed-by: adinn, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3052 From bpb at openjdk.java.net Thu Mar 18 23:39:02 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Mar 2021 23:39:02 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v5] In-Reply-To: References: Message-ID: <3LobFUMDSGPsKm0RbTL8SxUbNZIo-Ya3LZ6wIvueiM0=.2df4dbad-15f1-4376-860a-1eff55ece916@github.com> > Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. > > The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) > > In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. > > A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. > > Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 4833719: corrections pursuant to JDK-8263742 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2902/files - new: https://git.openjdk.java.net/jdk/pull/2902/files/6bd09bf9..1e2eac09 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2902/head:pull/2902 PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Thu Mar 18 23:53:03 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Mar 2021 23:53:03 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v6] In-Reply-To: References: Message-ID: > Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. > > The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) > > In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. > > A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. > > Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge - 4833719: corrections pursuant to JDK-8263742 - 4833719: Corrected faux pas in correcting faux pas - 4833719: Corrected faux pas in the slice(int,int) spec - 4833719: Remove @apiNotes and "A similar consideration" - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2902/files - new: https://git.openjdk.java.net/jdk/pull/2902/files/1e2eac09..3127ee0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2902&range=04-05 Stats: 49334 lines in 1942 files changed: 34875 ins; 8292 del; 6167 mod Patch: https://git.openjdk.java.net/jdk/pull/2902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2902/head:pull/2902 PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Thu Mar 18 23:56:39 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 18 Mar 2021 23:56:39 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v6] In-Reply-To: References: <0D4TrhDG9TocjIyXQspgWkA2gSJQWnadRRd3KSRwBv8=.b5ad1781-413a-44b1-83d5-353e4f009f8f@github.com> Message-ID: On Mon, 15 Mar 2021 21:39:02 GMT, Brian Burkhalter wrote: >> This looks good. > > CSR filed: https://bugs.openjdk.java.net/browse/JDK-8263620. Once the CSR is reviewed and appoved then this PR will be ready to integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Fri Mar 19 00:30:52 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Mar 2021 00:30:52 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists [v4] In-Reply-To: References: Message-ID: > Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. > > A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. > > The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8241619: Add FileAlreadyExistsException to AsynchronousFileChannel.open() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2980/files - new: https://git.openjdk.java.net/jdk/pull/2980/files/58c33e82..fdf41699 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2980&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2980&range=02-03 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2980.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2980/head:pull/2980 PR: https://git.openjdk.java.net/jdk/pull/2980 From bpb at openjdk.java.net Fri Mar 19 00:30:52 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Mar 2021 00:30:52 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 08:52:33 GMT, Alan Bateman wrote: >> Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. >> >> A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. >> >> The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. > > Are you planning to link the use of "optional specific exception" in FileChannel to the section in the java.nio.file package description? Also if we are adding optional specific exceptions to FileChannel.open then we'll have to do the same for AsynchronousFileChannel.open. Added "optional specific exception" link to `FileChannel.open()` and `@throws FileAlreadyExistsException` to `AsynchronousFileChannel.open(). ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From bpb at openjdk.java.net Fri Mar 19 00:38:38 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Mar 2021 00:38:38 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists In-Reply-To: References: Message-ID: On Fri, 19 Mar 2021 00:27:44 GMT, Brian Burkhalter wrote: >> Are you planning to link the use of "optional specific exception" in FileChannel to the section in the java.nio.file package description? Also if we are adding optional specific exceptions to FileChannel.open then we'll have to do the same for AsynchronousFileChannel.open. > > Added "optional specific exception" link to `FileChannel.open()` and `@throws FileAlreadyExistsException` to `AsynchronousFileChannel.open(). The CSR https://bugs.openjdk.java.net/browse/JDK-8263623 is also updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From mik3hall at gmail.com Fri Mar 19 20:11:45 2021 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 19 Mar 2021 15:11:45 -0500 Subject: Replacing default FileSystemProvider Message-ID: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> This may not be the correct forum to ask about this. If I should try posting to StackOverflow or elsewhere that?s fine if you indicate that. I wrote a Mac specific FileSystemProvider sometime back that replaced the default, prior to Java 9 modular.I get exceptions shortened to ones that follow at the end. I shortened that to as simple a test case as possible. public class Test { public static void main(String [] args) { System.out.println(FileSystems.getDefault()); } } class TestProvider extends FileSystemProvider { private final FileSystemProvider priorProvider; private static final String scheme = "file?; ? } Which gets the same exceptions. I?ve noticed there were similar issues with getDefault() returning null about the time of Java 9 modular. Are any of these issues still open? Is there anything different that should be done now? Is there any documentation I should look at? The exceptions? java -cp test.jar -Djava.nio.file.spi.DefaultFileSystemProvider=org.test.TestProvider -d . Test.java Exception in thread "main" java.lang.Error: java.lang.NullPointerException: Cannot invoke "java.nio.file.FileSystem.getPath(String, String[])" because the return value of "java.nio.file.FileSystems.getDefault()" is null at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100) Both the old code and the simpler test case seem to get these in pairs. Caused by: java.lang.NullPointerException: Cannot invoke "java.nio.file.FileSystem.getPath(String, String[])" because the return value of "java.nio.file.FileSystems.getDefault()" is null at java.base/java.io.File.toPath(File.java:2316) From brian.burkhalter at oracle.com Fri Mar 19 20:53:24 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 19 Mar 2021 13:53:24 -0700 Subject: Replacing default FileSystemProvider In-Reply-To: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> Message-ID: <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> This is the correct forum. I would have to investigate this to give you an answer. Certainly Alan will have something to write but as he is in Europe I doubt it will be today. If this thread is not resolved before then, I will look into this on Monday. > On Mar 19, 2021, at 1:11 PM, Michael Hall wrote: > > This may not be the correct forum to ask about this. If I should try posting to StackOverflow or elsewhere that?s fine if you indicate that. > > I wrote a Mac specific FileSystemProvider sometime back that replaced the default, prior to Java 9 modular.I get exceptions shortened to ones that follow at the end. I shortened that to as simple a test case as possible. > > public class Test { > > public static void main(String [] args) { > System.out.println(FileSystems.getDefault()); > } > > } > > class TestProvider extends FileSystemProvider { > private final FileSystemProvider priorProvider; > private static final String scheme = "file?; > > ? > > } > > Which gets the same exceptions. I?ve noticed there were similar issues with getDefault() returning null about the time of Java 9 modular. > Are any of these issues still open? Is there anything different that should be done now? Is there any documentation I should look at? > > The exceptions? > > java -cp test.jar -Djava.nio.file.spi.DefaultFileSystemProvider=org.test.TestProvider -d . Test.java > Exception in thread "main" java.lang.Error: java.lang.NullPointerException: Cannot invoke "java.nio.file.FileSystem.getPath(String, String[])" because the return value of "java.nio.file.FileSystems.getDefault()" is null > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100) > > Both the old code and the simpler test case seem to get these in pairs. > > Caused by: java.lang.NullPointerException: Cannot invoke "java.nio.file.FileSystem.getPath(String, String[])" because the return value of "java.nio.file.FileSystems.getDefault()" is null > at java.base/java.io.File.toPath(File.java:2316) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Fri Mar 19 21:09:31 2021 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 19 Mar 2021 16:09:31 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> Message-ID: <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> > On Mar 19, 2021, at 3:53 PM, Brian Burkhalter wrote: > > This is the correct forum. > > I would have to investigate this to give you an answer. Certainly Alan will have something to write but as he is in Europe I doubt it will be today. > > If this thread is not resolved before then, I will look into this on Monday. I had hoped for something obvious I missed. If it will require looking into the complete simple test case is here? http://mikehall.pairserver.com/testfsp.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Fri Mar 19 21:44:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 19 Mar 2021 21:44:43 GMT Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9] In-Reply-To: <84oaCizi9wr-vVk-L4OwgmBH8kdLBx5gzy7pejtfko8=.a3d79db9-f147-450e-8d3c-fc491cfa12fe@github.com> References: <84oaCizi9wr-vVk-L4OwgmBH8kdLBx5gzy7pejtfko8=.a3d79db9-f147-450e-8d3c-fc491cfa12fe@github.com> Message-ID: On Sun, 14 Mar 2021 12:57:01 GMT, Alan Bateman wrote: >> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: >> >> - Merge master >> - Fix bug in CharArrayReader and add unit test >> - Clean up unit tests >> - Revert off-heap code path >> - Replace c-style array declarations >> - Share work buffer between #skip and #read >> - Update copyright year >> - Implement review comment >> - Revert StreamDecoder changes >> - Implement CharArrayReader#read(CharBuffer) >> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0 > > src/java.base/share/classes/java/io/Reader.java line 205: > >> 203: target.put(cbuf, 0, nread); >> 204: } >> 205: return nread; > > Thanks for bringing this back to just the heap buffer case. This part looks good now. Agreed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1915 From mik3hall at gmail.com Fri Mar 19 21:49:31 2021 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 19 Mar 2021 16:49:31 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> Message-ID: <458C5870-2D29-4B58-969E-B8C95FFF7A0C@gmail.com> > On Mar 19, 2021, at 3:53 PM, Brian Burkhalter wrote: > > This is the correct forum. > > I would have to investigate this to give you an answer. Certainly Alan will have something to write but as he is in Europe I doubt it will be today. > > If this thread is not resolved before then, I will look into this on Monday. > The part I actually need for jdk16 seems to get by on JNI without the Mac FileSystemProvider dependency. So no rush. But would be good to know sometime. From brian.burkhalter at oracle.com Fri Mar 19 21:59:03 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 19 Mar 2021 14:59:03 -0700 Subject: Replacing default FileSystemProvider In-Reply-To: <458C5870-2D29-4B58-969E-B8C95FFF7A0C@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <458C5870-2D29-4B58-969E-B8C95FFF7A0C@gmail.com> Message-ID: <87CBD33F-97A0-4342-A77D-A822CCAC690B@oracle.com> > On Mar 19, 2021, at 2:49 PM, Michael Hall wrote: > >> On Mar 19, 2021, at 3:53 PM, Brian Burkhalter > wrote: >> >> This is the correct forum. >> >> I would have to investigate this to give you an answer. Certainly Alan will have something to write but as he is in Europe I doubt it will be today. >> >> If this thread is not resolved before then, I will look into this on Monday. >> > > The part I actually need for jdk16 seems to get by on JNI without the Mac FileSystemProvider dependency. > So no rush. But would be good to know sometime. Glad to hear it. Thanks for the notice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Fri Mar 19 22:04:59 2021 From: mik3hall at gmail.com (Michael Hall) Date: Fri, 19 Mar 2021 17:04:59 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <87CBD33F-97A0-4342-A77D-A822CCAC690B@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <458C5870-2D29-4B58-969E-B8C95FFF7A0C@gmail.com> <87CBD33F-97A0-4342-A77D-A822CCAC690B@oracle.com> Message-ID: <267923D4-2B50-43AE-A377-B3DCD74FF717@gmail.com> > On Mar 19, 2021, at 4:59 PM, Brian Burkhalter wrote: > > >> On Mar 19, 2021, at 2:49 PM, Michael Hall > wrote: >> >>> On Mar 19, 2021, at 3:53 PM, Brian Burkhalter > wrote: >>> >>> This is the correct forum. >>> >>> I would have to investigate this to give you an answer. Certainly Alan will have something to write but as he is in Europe I doubt it will be today. >>> >>> If this thread is not resolved before then, I will look into this on Monday. >>> >> >> The part I actually need for jdk16 seems to get by on JNI without the Mac FileSystemProvider dependency. >> So no rush. But would be good to know sometime. > > Glad to hear it. Thanks for the notice. Yes. Application is running again. A full replacement I have for the com.apple.eio.FileManager class removed or made inaccessible at 16 that broke the app would need the FileSystemProvider -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Sat Mar 20 07:16:01 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 20 Mar 2021 12:46:01 +0530 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com> References: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com> <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com> <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com> <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com> Message-ID: On 17/03/21 3:16 pm, Jaikiran Pai wrote: > > On 17/03/21 3:10 pm, Jaikiran Pai wrote: >> Hello Alan, >> >> On 17/03/21 2:45 pm, Alan Bateman wrote: >>> On 17/03/2021 08:21, Jaikiran Pai wrote: >>>> : >>>> >>>> I can confirm that using "NUL" or "nul" work fine in the above code, >>> >>> I don't know the context for your question >> >> ... >> > FWIW - that bug report states that they ran into this even when using > "nul" and not just "nul:". So there might be something more going on > here and am just waiting to see if they can provide us a build file to > reproduce this issue. I received some inputs on that Ant bugzilla issue. Based on that, I was able to reproduce the exception and IMO it's a bug in Files.newOutputStream() API. I have opened https://bugs.openjdk.java.net/browse/JDK-8263898 with the relevant details. I considered this a bug and took the liberty of opening that JBS issue because as I note in that issue, this only happens specifically when TRUNCATE_EXISTING (default) option gets used against "nul" on Windows. -Jaikiran From Alan.Bateman at oracle.com Sat Mar 20 07:48:20 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Mar 2021 07:48:20 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> Message-ID: <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> On 19/03/2021 21:09, Michael Hall wrote: > : > > I had hoped for something obvious I missed. > > If it will require looking into the complete simple test case is here? > > http://mikehall.pairserver.com/testfsp.zip > > The default file system provider is called to create the default file system so your TestProvider's getFileSystem(URI) method is invoked to create the "file:///" file system. It looks like your TestProvider is returning null so I assume this is why you are seeing NPE (assuming TestProvider is representative of the actual file system provider you are using). There is more detail on the javadoc of FileSystem.getDefault(). One of your mails mentions that you have a replacement for com.apple.eio.FileManager. Can you say more about this? Are you the submitter of JDK-8187981[1] ? That issue is looking for improve macOS/desktop integration but it pre-dates several APIs on java.awt.Desktop and other features, maybe it can be closed? -Alan. [1] https://bugs.openjdk.java.net/browse/JDK-8187981 From mik3hall at gmail.com Sat Mar 20 11:31:06 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 20 Mar 2021 06:31:06 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> Message-ID: > On Mar 20, 2021, at 2:48 AM, Alan Bateman wrote: > > On 19/03/2021 21:09, Michael Hall wrote: >> : >> >> I had hoped for something obvious I missed. >> >> If it will require looking into the complete simple test case is here? >> >> http://mikehall.pairserver.com/testfsp.zip >> > The default file system provider is called to create the default file system so your TestProvider's getFileSystem(URI) method is invoked to create the "file:///" file system. It looks like your TestProvider is returning null so I assume this is why you are seeing NPE (assuming TestProvider is representative of the actual file system provider you are using). There is more detail on the javadoc of FileSystem.getDefault(). The original MacFileSystemProvider had this? @Override public FileSystem getFileSystem(URI uri) { if (uri.getScheme().equals(scheme)) return new MacFileSystem(this,priorProvider); else return priorProvider.getFileSystem(uri); } So it shouldn?t be the error with that. I?ll try to improve the TestProvider so this is not the error. And verify the errors are the same although I think they were still pretty similar. Not able to do that immediately. > > One of your mails mentions that you have a replacement for com.apple.eio.FileManager. Can you say more about this? Are you the submitter of JDK-8187981[1] ? That issue is looking for improve macOS/desktop integration but it pre-dates several APIs on java.awt.Desktop and other features, maybe it can be closed? > > -Alan. > > [1] https://bugs.openjdk.java.net/browse/JDK-8187981 I may of submitted that bug report. I certainly added to it. Having com.apple.eio.FileManager inaccessible at jdk 16 sort of escalates matters. I assume it?s still there somewhere because the error indicated that the Desktop module didn?t export it. java.awt.Desktop currently does replace a lot of the major functionality FileManager had. But not some of the more Mac specific sort of lower level stuff. I did the replacement probably back around macports time. So it?s been around probably about as long as the bug report. As long as the JDK continued to provide the original it was sort of moot. For my use yes the replacement I did should suffice. Based on what Apple provided for macports it is in fact partially the original. I replaced some parts based on the MacFileSystemProvider I did. If that worked it should work for about anyone pretty much as the original did. I can certainly have that on GitHub. But there is obviously a difference in me providing it and the JDK providing it. Your risk would be others code failing who don?t know about a replacement. If that merits keeping the bug report open would be up to you. Like having it available in the first place. Enough of the replacement worked without the FileSystemProvider so that my application works. The same code of mine included in the bug report I think. The FileSystemProvider part working if I was going to claim it as a true replacement would be nice. From mik3hall at gmail.com Sat Mar 20 20:15:35 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 20 Mar 2021 15:15:35 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> Message-ID: <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> >>> >> The default file system provider is called to create the default file system so your TestProvider's getFileSystem(URI) method is invoked to create the "file:///" file system. It looks like your TestProvider is returning null so I assume this is why you are seeing NPE (assuming TestProvider is representative of the actual file system provider you are using). There is more detail on the javadoc of FileSystem.getDefault(). > Getting a bit confusing on the simple test case. For some reason currently I get ClassNotFoundExceptions on the provider org.test.TestProvider with -cp ./test.jar I don?t if I fallback to 1.8 or include the current directory with the compiled org/test/*class. Like -cp .:./test.jar If no obvious suggestions I?ll get back to doing my own debugging against my actual provider. Thanks for replies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sat Mar 20 22:24:20 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 20 Mar 2021 22:24:20 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> , <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> Message-ID: Maybe the provider is resolved against the platform classloader? I would think replacing the default provider wasn?t done much before (and not sure if it?s a good idea?). It seems to be good for new form of app sandboxing (but won?t cover old java.io api). So if it only helps for new api consumers, those should allow to specify a base filesystem(root) anyway? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: nio-dev im Auftrag von Michael Hall Gesendet: Samstag, M?rz 20, 2021 9:16 PM An: Alan Bateman Cc: Brian Burkhalter; nio-dev at openjdk.java.net Betreff: Re: Replacing default FileSystemProvider The default file system provider is called to create the default file system so your TestProvider's getFileSystem(URI) method is invoked to create the "file:///" file system. It looks like your TestProvider is returning null so I assume this is why you are seeing NPE (assuming TestProvider is representative of the actual file system provider you are using). There is more detail on the javadoc of FileSystem.getDefault(). Getting a bit confusing on the simple test case. For some reason currently I get ClassNotFoundExceptions on the provider org.test.TestProvider with -cp ./test.jar I don?t if I fallback to 1.8 or include the current directory with the compiled org/test/*class. Like -cp .:./test.jar If no obvious suggestions I?ll get back to doing my own debugging against my actual provider. Thanks for replies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Sat Mar 20 23:30:39 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 20 Mar 2021 18:30:39 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> Message-ID: <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> > On Mar 20, 2021, at 5:24 PM, Bernd Eckenfels wrote: > > Maybe the provider is resolved against the platform classloader? > > I would think replacing the default provider wasn?t done much before (and not sure if it?s a good idea?). It seems to be good for new form of app sandboxing (but won?t cover old java.io api). So if it only helps for new api consumers, those should allow to specify a base filesystem(root) anyway? > The idea wasn?t to completely replace the default ?file? provider but to expose some native API?s through nio attributes. The main use I am remembering. For other purposes it served as a passthrough to the usual default. So for the FileManager replacement that was being discussed earlier there could be? Files.setAttribute(p, "mac_finder:type", new String(b)); pokeInt(b,0,creator); Files.setAttribute(p, "mac_finder:creator", new String(b)); mac_finder would be the API concerned followed by the attribute. I had attributes for 3 or 4 native API?s. I have found there does seem to be something version related going on at least? /usr/libexec/java_home -v 1.8 --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Conents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test class us.hall.trz.osx.MacFileSystem (base) Michaels-MacBook-Pro:halfpipe_jpkg mjh$ /usr/libexec/java_home --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Contents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test Exception in thread "main" java.lang.Error: java.lang.NullPointerException: Cannot invoke "java.nio.file.FileSystem.getPath(String, String[])" because the return value of "java.nio.file.FileSystems.getDefault()" is null at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:100) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:182) ... From ecki at zusammenkunft.net Sun Mar 21 00:01:27 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 21 Mar 2021 00:01:27 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> , <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> Message-ID: Hello Michael, If your App expects additional attributes it could be custom enough to request custom provider, it seems like you don?t need to replace the system wide default, which is easier. I am not sure if it is easy to stay within a filesystem provider, but I expect as long as the app does not repeatingly resolve file URLs that should work.. (with Apache VFS that would be harder) Do you have a simple reproducer sample for testing? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Michael Hall Gesendet: Sonntag, M?rz 21, 2021 12:30 AM An: Bernd Eckenfels Cc: nio-dev at openjdk.java.net Betreff: Re: Replacing default FileSystemProvider > On Mar 20, 2021, at 5:24 PM, Bernd Eckenfels wrote: > > Maybe the provider is resolved against the platform classloader? > > I would think replacing the default provider wasn?t done much before (and not sure if it?s a good idea?). It seems to be good for new form of app sandboxing (but won?t cover old java.io api). So if it only helps for new api consumers, those should allow to specify a base filesystem(root) anyway? > The idea wasn?t to completely replace the default ?file? provider but to expose some native API?s through nio attributes. The main use I am remembering. For other purposes it served as a passthrough to the usual default. So for the FileManager replacement that was being discussed earlier there could be? Files.setAttribute(p, "mac_finder:type", new String(b)); pokeInt(b,0,creator); Files.setAttribute(p, "mac_finder:creator", new String(b)); mac_finder would be the API concerned followed by the attribute. I had attributes for 3 or 4 native API?s. I have found there does seem to be something version related going on at least? /usr/libexec/java_home -v 1.8 --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Conents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test class us.hall.trz.osx.MacFileSystem (base) Michaels-MacBook-Pro:halfpipe_jpkg mjh$ /usr/libexec/java_home --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Contents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test Exception in thread "main" java.lang.Error: java.lang.NullPointerException: Cannot invoke "java.nio.file.FileSystem.getPath(String, String[])" because the return value of "java.nio.file.FileSystems.getDefault()" is null at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:100) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:182) ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Sun Mar 21 00:10:30 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 20 Mar 2021 19:10:30 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> Message-ID: > On Mar 20, 2021, at 7:01 PM, Bernd Eckenfels wrote: > > Hello Michael, > > If your App expects additional attributes it could be custom enough to request custom provider, it seems like you don?t need to replace the system wide default, which is easier. > The provider itself was intended for use by any application that wanted java access to the supported Mac native api?s. The FileManager class demonstrated such application usage. > I am not sure if it is easy to stay within a filesystem provider, but I expect as long as the app does not repeatingly resolve file URLs that should work.. (with Apache VFS that would be harder) > > Do you have a simple reproducer sample for testing? > I did. Earlier in this thread I had provided a simple test case. When I didn?t seem to be making progress there I went back to my full code. I could probably reproduce the java 1.8 works, current doesn?t from my prior with the simple test case if the nio people indicate an interest. Not familiar with Apache VFS -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Mar 21 08:14:29 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Mar 2021 08:14:29 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> Message-ID: <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> On 20/03/2021 23:30, Michael Hall wrote: > : > The idea wasn?t to completely replace the default ?file? provider but to expose some native API?s through nio attributes. The main use I am remembering. For other purposes it served as a passthrough to the usual default. > > So for the FileManager replacement that was being discussed earlier there could be? > > Files.setAttribute(p, "mac_finder:type", new String(b)); > pokeInt(b,0,creator); > Files.setAttribute(p, "mac_finder:creator", new String(b)); > > mac_finder would be the API concerned followed by the attribute. > I had attributes for 3 or 4 native API?s. Maybe I have this wrong but I thought that the type/creator codes have been obsolete for more than 10 years. That is, I think macOS ignores them but maybe are working with programs that still use them? I did a quick test with SetFile/GetFile (these programs are deprecated but are still included with Xcode) and I see that they are storing the codes in an extended attribute named "com.apple.FinderInfo". If you know the format then it means they you should be able to use the UserFileAttributeView to access them (Sebastian Stenzel did great work to implement this attribute view on macOS recently). -Alan. From mik3hall at gmail.com Sun Mar 21 08:35:08 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 21 Mar 2021 03:35:08 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> Message-ID: > On Mar 21, 2021, at 3:14 AM, Alan Bateman wrote: > > On 20/03/2021 23:30, Michael Hall wrote: >> : >> The idea wasn?t to completely replace the default ?file? provider but to expose some native API?s through nio attributes. The main use I am remembering. For other purposes it served as a passthrough to the usual default. >> >> So for the FileManager replacement that was being discussed earlier there could be? >> >> Files.setAttribute(p, "mac_finder:type", new String(b)); >> pokeInt(b,0,creator); >> Files.setAttribute(p, "mac_finder:creator", new String(b)); >> >> mac_finder would be the API concerned followed by the attribute. >> I had attributes for 3 or 4 native API?s. > Maybe I have this wrong but I thought that the type/creator codes have been obsolete for more than 10 years. That is, I think macOS ignores them but maybe are working with programs that still use them? > > I did a quick test with SetFile/GetFile (these programs are deprecated but are still included with Xcode) and I see that they are storing the codes in an extended attribute named "com.apple.FinderInfo". If you know the format then it means they you should be able to use the UserFileAttributeView to access them (Sebastian Stenzel did great work to implement this attribute view on macOS recently). > > -Alan. It?s been a while since I looked at any of this. I believe the mac_finder API corresponded to the old Carbon File stuff. It is still there if used much currently or not. It is/was supported by the com.apple.eio.FileManager class so it made sense there. So far I haven?t been able to duplicate the error with the simple test case. The error does appear to begin right after 1.8 at java 9. It seems similar to these issues? https://bugs.openjdk.java.net/browse/JDK-8058876 . Overriding the default file system provider fails with a modular image https://bugs.openjdk.java.net/browse/JDK-8059939 . java/nio/file/spi/SetDefaultProvider.java fails with modular image -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Mar 21 09:15:30 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Mar 2021 09:15:30 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> Message-ID: <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> On 21/03/2021 08:35, Michael Hall wrote: > : > > So far I haven?t been able to duplicate the error with the simple test > case. The error does appear to begin right after 1.8 at java 9. > > It seems similar to these issues? > https://bugs.openjdk.java.net/browse/JDK-8058876 > .?Overriding the > default file system provider fails with a modular image > https://bugs.openjdk.java.net/browse/JDK-8059939 > .?java/nio/file/spi/SetDefaultProvider.java > fails with modular image > Those issues were in the jigsaw repo so didn't impact any GA release. That said, there has been refactoring in this area since JDK 8 in order to allow access to the file system during VM initialization. This all happens before a custom file system provider is located and set. So are you saying that the NPE started with JDK 9 or a more recent release? We have tests that exercise this mechanism so I would be surprised if there is something fundamentally broken. The only other thing that comes to mind is the zip/JAR code which has changed significantly in recent releases (the zip/JAR code needs to use the builtin file system provider when accessing the file system to load the custom file system provider). Finally, just to rule this out, your provider isn't making direct use of the sun.nio.* classes, right? -Alan From mik3hall at gmail.com Sun Mar 21 10:04:05 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 21 Mar 2021 05:04:05 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> Message-ID: <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> > On Mar 21, 2021, at 4:15 AM, Alan Bateman wrote: > > On 21/03/2021 08:35, Michael Hall wrote: >> : >> >> So far I haven?t been able to duplicate the error with the simple test case. The error does appear to begin right after 1.8 at java 9. >> >> It seems similar to these issues? >> https://bugs.openjdk.java.net/browse/JDK-8058876 . Overriding the default file system provider fails with a modular image >> https://bugs.openjdk.java.net/browse/JDK-8059939 . java/nio/file/spi/SetDefaultProvider.java fails with modular image >> > Those issues were in the jigsaw repo so didn't impact any GA release. > > That said, there has been refactoring in this area since JDK 8 in order to allow access to the file system during VM initialization. This all happens before a custom file system provider is located and set. So are you saying that the NPE started with JDK 9 or a more recent release? We have tests that exercise this mechanism so I would be surprised if there is something fundamentally broken. The only other thing that comes to mind is the zip/JAR code which has changed significantly in recent releases (the zip/JAR code needs to use the builtin file system provider when accessing the file system to load the custom file system provider). Finally, just to rule this out, your provider isn't making direct use of the sun.nio.* classes, right? > > -Alan Starts at 9. 1.8 works /usr/libexec/java_home -v 1.8 --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Conents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test class us.hall.trz.osx.MacFileSystem Java 9 does not (base) Michaels-MacBook-Pro:halfpipe_jpkg mjh$ /usr/libexec/java_home -v 9 --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Conents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test Exception in thread "main" java.lang.Error: java.lang.NullPointerException at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:141) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:102) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:111) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) at java.base/java.security.AccessController.doPrivileged(Native Method) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:109) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:103) at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:190) at Test.main(Test.java:6) Caused by: java.lang.NullPointerException at java.base/java.io.File.toPath(File.java:2300) /usr/libexec/java_home -v 9 --exec java -version java version "9" Java(TM) SE Runtime Environment (build 9+181) Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode) The double NPE looks like the jigsaw issues I thought. From mik3hall at gmail.com Sun Mar 21 15:17:00 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 21 Mar 2021 10:17:00 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> Message-ID: > On Mar 21, 2021, at 5:04 AM, Michael Hall wrote: > >> Finally, just to rule this out, your provider isn't making direct use of the sun.nio.* classes, right? Sorry missed this. Nowhere do I directly or intentionally use any sun classes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Mar 21 15:20:30 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Mar 2021 15:20:30 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> Message-ID: <21995c18-d611-555a-22a2-e3be21061f84@oracle.com> On 21/03/2021 10:04, Michael Hall wrote: > (base) Michaels-MacBook-Pro:halfpipe_jpkg mjh$ /usr/libexec/java_home -v 9 --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Conents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test > Exception in thread "main" java.lang.Error: java.lang.NullPointerException > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:141) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:102) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:111) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:109) > at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:103) > at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:190) > at Test.main(Test.java:6) > Caused by: java.lang.NullPointerException > at java.base/java.io.File.toPath(File.java:2300) > Thanks, I understand this now and I can duplicate it. The issue is re-implementation and other work on ZipFile means leads to a bootstrapping issue when the default provider is override and deployed in JAR file. Thanks for persisting with the mails on this, I'll create a bug to track this. -Alan From mik3hall at gmail.com Sun Mar 21 16:54:05 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 21 Mar 2021 11:54:05 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <21995c18-d611-555a-22a2-e3be21061f84@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> <21995c18-d611-555a-22a2-e3be21061f84@oracle.com> Message-ID: > On Mar 21, 2021, at 10:20 AM, Alan Bateman wrote: > > On 21/03/2021 10:04, Michael Hall wrote: >> (base) Michaels-MacBook-Pro:halfpipe_jpkg mjh$ /usr/libexec/java_home -v 9 --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Conents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test >> Exception in thread "main" java.lang.Error: java.lang.NullPointerException >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:141) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:102) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:111) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:109) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:103) >> at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:190) >> at Test.main(Test.java:6) >> Caused by: java.lang.NullPointerException >> at java.base/java.io.File.toPath(File.java:2300) >> > Thanks, I understand this now and I can duplicate it. The issue is re-implementation and other work on ZipFile means leads to a bootstrapping issue when the default provider is override and deployed in JAR file. Thanks for persisting with the mails on this, I'll create a bug to track this. > > -Alan Thank you for the quick determination. From mik3hall at gmail.com Sun Mar 21 21:46:18 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 21 Mar 2021 16:46:18 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <21995c18-d611-555a-22a2-e3be21061f84@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> <21995c18-d611-555a-22a2-e3be21061f84@oracle.com> Message-ID: <1C5B0495-F500-4FB4-B33A-1E34CE61B585@gmail.com> > On Mar 21, 2021, at 10:20 AM, Alan Bateman wrote: > > On 21/03/2021 10:04, Michael Hall wrote: >> (base) Michaels-MacBook-Pro:halfpipe_jpkg mjh$ /usr/libexec/java_home -v 9 --exec java -cp .:outputdir/HalfPipe.app/Contents/app/macnio2.jar -Djava.library.path=outputdir/HalfPipe.app/Conents/app -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider Test >> Exception in thread "main" java.lang.Error: java.lang.NullPointerException >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:141) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.access$100(FileSystems.java:102) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:111) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:109) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:109) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:103) >> at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:190) >> at Test.main(Test.java:6) >> Caused by: java.lang.NullPointerException >> at java.base/java.io.File.toPath(File.java:2300) >> > Thanks, I understand this now and I can duplicate it. The issue is re-implementation and other work on ZipFile means leads to a bootstrapping issue when the default provider is override and deployed in JAR file. Thanks for persisting with the mails on this, I'll create a bug to track this. > > -Alan Could you forward the bug report number when you have one? I would like to re-do some of the GitHub related to this and com.apple.eio.FileManager when I know this will work current. So track the bug a little myself. Thanks again. From mik3hall at gmail.com Sun Mar 21 23:09:16 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 21 Mar 2021 18:09:16 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> Message-ID: > > I did a quick test with SetFile/GetFile (these programs are deprecated but are still included with Xcode) and I see that they are storing the codes in an extended attribute named "com.apple.FinderInfo". If you know the format then it means they you should be able to use the UserFileAttributeView to access them (Sebastian Stenzel did great work to implement this attribute view on macOS recently). Had to review what I had. Actually, mac_xattr is one of the API?s I supported nio attributes for? Map attrs = Files.readAttributes(p,"mac_xattr:*"); assertEquals(2,attrs.size()); assertTrue(attrs.containsKey("mac_xattr:com.apple.FinderInfo")); byte[] finfo = (byte[])attrs.get("mac_xattr:com.apple.FinderInfo"); assertEquals(32,finfo.length); There was some redundancy across API?s. There is also the LaunchServices API if (!((Boolean)Files.getAttribute(p,"mac_ls:application")).booleanValue()) { One use is information about the default application associated with a file. And mac_cocoa for the NS API family assertFalse(((Boolean)Files.getAttribute(p,"mac_cocoa:NSFileBusy")).booleanValue()); assertEquals(Files.size(p),((Long)Files.getAttribute(p,"mac_cocoa:NSFileSize")).longValue()); attrs = Files.readAttributes(p,"mac_cocoa:NSFileModificationDate,mac_cocoa:NSFilePosixPermissions?); I?m not sure this API driven stuff would exactly translate to a user attribute view. From Alan.Bateman at oracle.com Mon Mar 22 08:34:49 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Mar 2021 08:34:49 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: <1C5B0495-F500-4FB4-B33A-1E34CE61B585@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> <21995c18-d611-555a-22a2-e3be21061f84@oracle.com> <1C5B0495-F500-4FB4-B33A-1E34CE61B585@gmail.com> Message-ID: <28936f6c-f1c2-92b0-ae26-0338c5ddec00@oracle.com> On 21/03/2021 21:46, Michael Hall wrote: > : > Could you forward the bug report number when you have one? I would like to re-do some of the GitHub related to this and com.apple.eio.FileManager when I know this will work current. So track the bug a little myself. > Here it is now (I didn't get time to create it yesterday) ? https://bugs.openjdk.java.net/browse/JDK-8263940 -Alan From Alan.Bateman at oracle.com Mon Mar 22 08:43:44 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Mar 2021 08:43:44 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> Message-ID: On 21/03/2021 23:09, Michael Hall wrote: > Had to review what I had. Actually, mac_xattr is one of the API?s I supported nio attributes for? > > Map attrs = Files.readAttributes(p,"mac_xattr:*"); > assertEquals(2,attrs.size()); > assertTrue(attrs.containsKey("mac_xattr:com.apple.FinderInfo")); > byte[] finfo = (byte[])attrs.get("mac_xattr:com.apple.FinderInfo"); > assertEquals(32,finfo.length); > > There was some redundancy across API?s. > > There is also the LaunchServices API > > if (!((Boolean)Files.getAttribute(p,"mac_ls:application")).booleanValue()) { > > One use is information about the default application associated with a file. > > And mac_cocoa for the NS API family > > assertFalse(((Boolean)Files.getAttribute(p,"mac_cocoa:NSFileBusy")).booleanValue()); > assertEquals(Files.size(p),((Long)Files.getAttribute(p,"mac_cocoa:NSFileSize")).longValue()); > attrs = Files.readAttributes(p,"mac_cocoa:NSFileModificationDate,mac_cocoa:NSFilePosixPermissions?); > > I?m not sure this API driven stuff would exactly translate to a user attribute view. The com.apple.eio.FileManager API was an API in Apple's JDK up to JDK 6. The code came into the OpenJDK when support for macOS was added in 7u4 but it wasn't tracked as a supported/documented interface. The java.desktop module can't export non-standard APIs so this is why it has been encapsulated (and not exposed) at compile-time since Java 9 (why you've had to compile with --add-exports java.desktop/com.apple.eio=... to compile code that uses it). It it encapsulated at run-time since Java 16. Many of the features that eio.FileManager provided are superseded by standard APIs and java.awt.Desktop. My understanding is that type/creator codes are legacy and have been ignored on macOS for 10 years so it might not be worth spending time trying to create a file attribute view for them. But maybe you have a good use case that involves interop with code that still make use of them? -Alan. From alanb at openjdk.java.net Mon Mar 22 08:58:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 22 Mar 2021 08:58:53 GMT Subject: RFR: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists [v4] In-Reply-To: References: Message-ID: <_ksvZdSMDFuifkIECBoWKTZ-kF__pazetiKFPJKa4AQ=.a5279de5-25b0-4d53-a45d-68077ecd1864@github.com> On Fri, 19 Mar 2021 00:30:52 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. >> >> A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. >> >> The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8241619: Add FileAlreadyExistsException to AsynchronousFileChannel.open() Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From Alan.Bateman at oracle.com Mon Mar 22 09:06:58 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 22 Mar 2021 09:06:58 +0000 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: References: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com> <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com> <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com> <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com> Message-ID: <1a500843-8b90-91e5-3257-b64f4fd0ef49@oracle.com> On 20/03/2021 07:16, Jaikiran Pai wrote: > : > > I received some inputs on that Ant bugzilla issue. Based on that, I > was able to reproduce the exception and IMO it's a bug in > Files.newOutputStream() API. I have opened > https://bugs.openjdk.java.net/browse/JDK-8263898 with the relevant > details. I considered this a bug and took the liberty of opening that > JBS issue because as I note in that issue, this only happens > specifically when TRUNCATE_EXISTING (default) option gets used against > "nul" on Windows. OutputStream.nullOutputStream() may be a better and more portable alternative. In general, the DOS era reserved names (including NUL) are very under specified and many file operations lead to surprising behavior (this isn't solely a JDK issue, I think other runtimes and languages also get tripped up). In this case, the attempt to truncate the file to zero length is failing. Sure, it can be be worked around but workarounds like this tend to cause issues in other unusual cases so care is required. -Alan. From jai.forums2013 at gmail.com Mon Mar 22 09:50:50 2021 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Mon, 22 Mar 2021 15:20:50 +0530 Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null device)? In-Reply-To: <1a500843-8b90-91e5-3257-b64f4fd0ef49@oracle.com> References: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com> <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com> <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com> <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com> <1a500843-8b90-91e5-3257-b64f4fd0ef49@oracle.com> Message-ID: <5614738c-34d5-73bb-ce84-31678528be40@gmail.com> On 22/03/21 2:36 pm, Alan Bateman wrote: > On 20/03/2021 07:16, Jaikiran Pai wrote: >> : >> >> I received some inputs on that Ant bugzilla issue. Based on that, I >> was able to reproduce the exception and IMO it's a bug in >> Files.newOutputStream() API. I have opened >> https://bugs.openjdk.java.net/browse/JDK-8263898 with the relevant >> details. I considered this a bug and took the liberty of opening that >> JBS issue because as I note in that issue, this only happens >> specifically when TRUNCATE_EXISTING (default) option gets used >> against "nul" on Windows. > > OutputStream.nullOutputStream() may be a better and more portable > alternative. In general, the DOS era reserved names (including NUL) > are very under specified and many file operations lead to surprising > behavior (this isn't solely a JDK issue, I think other runtimes and > languages also get tripped up). In this case, the attempt to truncate > the file to zero length is failing. Sure, it can be be worked around > but workarounds like this tend to cause issues in other unusual cases > so care is required. Understood. Thank you Alan for those inputs. Just yesterday, Stefan (one of the Ant developers) has implemented a way where we allow users to discard output without relying on null devices. It uses the approach that you note (although we use an internal NullOutputStream, since we want Ant to be usable in Java 8 where OutputStream.nullOutputStream() isn't present). We will be asking our users to move to this new way/attribute instead of relying on null devices. -Jaikiran From mik3hall at gmail.com Mon Mar 22 12:12:23 2021 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 22 Mar 2021 07:12:23 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> Message-ID: > On Mar 22, 2021, at 3:43 AM, Alan Bateman wrote: > > On 21/03/2021 23:09, Michael Hall wrote: >> Had to review what I had. Actually, mac_xattr is one of the API?s I supported nio attributes for? >> >> Map attrs = Files.readAttributes(p,"mac_xattr:*"); >> assertEquals(2,attrs.size()); >> assertTrue(attrs.containsKey("mac_xattr:com.apple.FinderInfo")); >> byte[] finfo = (byte[])attrs.get("mac_xattr:com.apple.FinderInfo"); >> assertEquals(32,finfo.length); >> >> There was some redundancy across API?s. >> >> There is also the LaunchServices API >> >> if (!((Boolean)Files.getAttribute(p,"mac_ls:application")).booleanValue()) { >> >> One use is information about the default application associated with a file. >> >> And mac_cocoa for the NS API family >> >> assertFalse(((Boolean)Files.getAttribute(p,"mac_cocoa:NSFileBusy")).booleanValue()); >> assertEquals(Files.size(p),((Long)Files.getAttribute(p,"mac_cocoa:NSFileSize")).longValue()); >> attrs = Files.readAttributes(p,"mac_cocoa:NSFileModificationDate,mac_cocoa:NSFilePosixPermissions?); >> >> I?m not sure this API driven stuff would exactly translate to a user attribute view. > The com.apple.eio.FileManager API was an API in Apple's JDK up to JDK 6. The code came into the OpenJDK when support for macOS was added in 7u4 but it wasn't tracked as a supported/documented interface. The java.desktop module can't export non-standard APIs so this is why it has been encapsulated (and not exposed) at compile-time since Java 9 Dropping it is as I?ve said your decision. But I had code from about 6 years back to replace it in this eventuality I might as well put into place now. > (why you've had to compile with --add-exports java.desktop/com.apple.eio=? I don?t remember having to do this but maybe Eclipse building my app didn?t involve recompiling this code since then. > to compile code that uses it). It it encapsulated at run-time since Java 16. Many of the features that eio.FileManager provided are superseded by standard APIs and java.awt.Desktop. My understanding is that type/creator codes are legacy and have been ignored on macOS for 10 years Code sometimes doesn?t do away so quickly or easily. Carbon supports it. Carbon is still around. I think type/creator were used for one thing in targeting AppleEvents, also still around, as-is AppleScript. Which I was all right with when java dropped it?s support. That was something else I salvaged during the macport project, the Apple JSR 223 engine, and I provide some support yet for that myself. Actually inspired by jpackage using AppleScript in setting up it?s disk image installs I have been looking to make sure my support of that is still what it should be. Some basic functionality seems to work as always. Apple security changes appear to have broken some support. I am currently looking at that. > so it might not be worth spending time trying to create a file attribute view for them. But maybe you have a good use case that involves interop with code that still make use of them? > > -Alan. My remaining use of the FileManager API?s was as shown in the old bug report you mentioned. I use it as part of some code to try and determine the best platform specific place to write different types of data on OS X. Others may have different use cases. I would prefer to offer full support of the class and not pick and choose as long as it is easily enough done and it should be. The Apple file API?s still have the type/creator methods, actually redundantly in a couple API?s I think. In providing nio API attributes again I preferred not to pick and choose but to provide as complete access to the API?s as possible. Some of it as was shown in one test case is redundant with java? >> assertEquals(Files.size(p),((Long)Files.getAttribute(p,"mac_cocoa:NSFileSize")).longValue()); That might even have uses. Maybe you?re wondering if the java size is correct. You can easily compare it to the Cocoa NSFileSize value.Some of it is hopefully not redundant and may also have uses. So it is not just type/creator I?m trying to preserve. But the full functionality of FileManager and also the FileManagerProvider access I did across the different OS X file API?s. I was thinking of splitting those out into a separate GitHub project. They are currently in my trz project but that is pretty messy also including code from a couple different botched efforts to come up with a Mac WatchService. Something I have still unfortunately not successfully managed. I would do the new GitHub project when I know the provider code is working. I am all right at this point if FileManager is dropped. I would just like to be able to provide my own for myself or whoever may hear about it and want to use it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.java.net Mon Mar 22 15:49:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 22 Mar 2021 15:49:53 GMT Subject: RFR: 8263979: Cleanup duplicate check in Unicode.contains Message-ID: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> SonarCloud reports an easy problem in Unicode.contains: Correct one of the identical sub-expressions on both sides of operator "||" ------------- Commit messages: - 8263979: Cleanup duplicate check in Unicode.contains Changes: https://git.openjdk.java.net/jdk/pull/3122/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3122&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263979 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3122.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3122/head:pull/3122 PR: https://git.openjdk.java.net/jdk/pull/3122 From prappo at openjdk.java.net Mon Mar 22 16:02:37 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 22 Mar 2021 16:02:37 GMT Subject: RFR: 8263979: Cleanup duplicate check in Unicode.contains In-Reply-To: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> References: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> Message-ID: On Mon, 22 Mar 2021 15:44:16 GMT, Aleksey Shipilev wrote: > SonarCloud reports an easy problem in Unicode.contains: > Correct one of the identical sub-expressions on both sides of operator "||" IntelliJ IDEA also reports this problem: Duplicate condition 'cs.name().equals("Big5-HKSCS")' Looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3122 From prappo at openjdk.java.net Mon Mar 22 16:06:39 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 22 Mar 2021 16:06:39 GMT Subject: RFR: 8263979: Cleanup duplicate check in Unicode.contains In-Reply-To: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> References: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> Message-ID: On Mon, 22 Mar 2021 15:44:16 GMT, Aleksey Shipilev wrote: > SonarCloud reports an easy problem in Unicode.contains: > Correct one of the identical sub-expressions on both sides of operator "||" Marked as reviewed by prappo (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3122 From alanb at openjdk.java.net Mon Mar 22 19:02:43 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 22 Mar 2021 19:02:43 GMT Subject: RFR: 8263979: Cleanup duplicate check in Unicode.contains In-Reply-To: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> References: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> Message-ID: On Mon, 22 Mar 2021 15:44:16 GMT, Aleksey Shipilev wrote: > SonarCloud reports an easy problem in Unicode.contains: > Correct one of the identical sub-expressions on both sides of operator "||" Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3122 From github.com+81080647+lyndseybeil at openjdk.java.net Tue Mar 23 04:58:50 2021 From: github.com+81080647+lyndseybeil at openjdk.java.net (lyndseyBeil) Date: Tue, 23 Mar 2021 04:58:50 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v6] In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 23:53:03 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. >> >> The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) >> >> In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. >> >> A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. >> >> Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge > - 4833719: corrections pursuant to JDK-8263742 > - 4833719: Corrected faux pas in correcting faux pas > - 4833719: Corrected faux pas in the slice(int,int) spec > - 4833719: Remove @apiNotes and "A similar consideration" > - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced test/jdk/java/nio/MappedByteBuffer/ForceViews.java line 48: > 46: public class ForceViews { > 47: > 48: static record Segment(int position, int length) {} I detect that this code is problematic. According to the [Bad practice (BAD_PRACTICE)](https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#bad-practice-bad-practice), [Nm: Method names should start with a lower case letter (NM_METHOD_NAMING_CONVENTION)](https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#nm-method-names-should-start-with-a-lower-case-letter-nm-method-naming-convention). Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From shade at openjdk.java.net Tue Mar 23 06:56:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 23 Mar 2021 06:56:40 GMT Subject: Integrated: 8263979: Cleanup duplicate check in Unicode.contains In-Reply-To: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> References: <8Ntk3GmlR-alG51Me_eYouW4u-M-sLeHXLFh1utcJSA=.4dd09a86-4c6b-476f-800b-abc9ecaac04a@github.com> Message-ID: On Mon, 22 Mar 2021 15:44:16 GMT, Aleksey Shipilev wrote: > SonarCloud reports an easy problem in Unicode.contains: > Correct one of the identical sub-expressions on both sides of operator "||" This pull request has now been integrated. Changeset: 4ef7c67b Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/4ef7c67b Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8263979: Cleanup duplicate check in Unicode.contains Reviewed-by: prappo, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3122 From github.com+741251+turbanoff at openjdk.java.net Tue Mar 23 12:24:01 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 23 Mar 2021 12:24:01 GMT Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base Message-ID: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'` As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base` Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679 ------------- Commit messages: - [PATCH] Replaces usages of StringBuffer with StringBuilder where appropriate in java.base Changes: https://git.openjdk.java.net/jdk/pull/2922/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2922&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264029 Stats: 12 lines in 3 files changed: 0 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/2922.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2922/head:pull/2922 PR: https://git.openjdk.java.net/jdk/pull/2922 From shade at openjdk.java.net Tue Mar 23 12:24:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 23 Mar 2021 12:24:02 GMT Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base In-Reply-To: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> Message-ID: On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov wrote: > Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'` > As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base` > Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679 This looks good to me. I have created the bug for it: https://bugs.openjdk.java.net/browse/JDK-8264029 -- please change the PR synopsis to "8264029: Replace uses of StringBuffer with StringBuilder in java.base" ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2922 From prappo at openjdk.java.net Tue Mar 23 12:40:41 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 23 Mar 2021 12:40:41 GMT Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base In-Reply-To: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> Message-ID: On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov wrote: > Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'` > As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base` > Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679 src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954: > 1952: for (int i = 0; i < 4; ++i) { > 1953: if (i > 0) { > 1954: sb.append(" "); Consider using `String.repeat` here and on L1960 for clarity. src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954: > 1952: for (int i = 0; i < 4; ++i) { > 1953: if (i > 0) { > 1954: sb.append(" "); Consider using `String.repeat` here and on L1960 for clarity. ------------- PR: https://git.openjdk.java.net/jdk/pull/2922 From mik3hall at gmail.com Tue Mar 23 13:28:34 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 23 Mar 2021 08:28:34 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <28936f6c-f1c2-92b0-ae26-0338c5ddec00@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <1f050d73-f47e-a09e-192d-096c91e92972@oracle.com> <75B7A953-5863-4F8E-A6B9-F12436A65D26@gmail.com> <21995c18-d611-555a-22a2-e3be21061f84@oracle.com> <1C5B0495-F500-4FB4-B33A-1E34CE61B585@gmail.com> <28936f6c-f1c2-92b0-ae26-0338c5ddec00@oracle.com> Message-ID: > On Mar 22, 2021, at 3:34 AM, Alan Bateman wrote: > > On 21/03/2021 21:46, Michael Hall wrote: >> : >> Could you forward the bug report number when you have one? I would like to re-do some of the GitHub related to this and com.apple.eio.FileManager when I know this will work current. So track the bug a little myself. >> > Here it is now (I didn't get time to create it yesterday) > https://bugs.openjdk.java.net/browse/JDK-8263940 > > -Alan Thank you. Fwiw verbose class loading seems to indicate a security check is failing? [0.143s][info][class,load] java.util.zip.ZipFile$Source source: jrt:/java.base [0.143s][info][class,load] java.util.zip.ZipFile$Source$Key source: jrt:/java.base [0.143s][info][class,load] java.security.PrivilegedActionException source: jrt:/java.base [0.144s][info][class,load] java.io.IOException source: jrt:/java.base [0.144s][info][class,load] java.lang.SecurityException source: jrt:/java.base Exception in thread "main" [0.145s][info][class,load] java.lang.Throwable$PrintStreamOrWriter source: jrt:/java.base If I?m interpreting that correctly. Or the IOException is being turned into a security exception. From mik3hall at gmail.com Tue Mar 23 13:36:55 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 23 Mar 2021 08:36:55 -0500 Subject: Why does Path check for the Default FileSystem? Message-ID: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> May I ask why the default FileSystem is checked for here? default File toFile() { if (getFileSystem() == FileSystems.getDefault()) { return new File(toString()); } else { throw new UnsupportedOperationException("Path not associated with " + "default file system."); } } For my custom DefaultFileSystemProvider I found it necessary to have my own Path class. Most of mine is passthrough and for the Path class I keep a proxy platform provider Path that I use for almost all functionality. This check now seems to fail this? Is it necessary to be the default or would also being for the default ?file? scheme be good enough? From Alan.Bateman at oracle.com Tue Mar 23 13:41:32 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Mar 2021 13:41:32 +0000 Subject: Why does Path check for the Default FileSystem? In-Reply-To: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> References: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> Message-ID: <8728cbe9-1f41-e759-9412-560ff129c803@oracle.com> On 23/03/2021 13:36, Michael Hall wrote: > May I ask why the default FileSystem is checked for here? > > default File toFile() { > if (getFileSystem() == FileSystems.getDefault()) { > return new File(toString()); > } else { > throw new UnsupportedOperationException("Path not associated with " > + "default file system."); > } > } > > For my custom DefaultFileSystemProvider I found it necessary to have my own Path class. > Most of mine is passthrough and for the Path class I keep a proxy platform provider Path that I use for almost all functionality. > This check now seems to fail this? > Is it necessary to be the default or would also being for the default ?file? scheme be good enough? A java.io.File cannot represent a file in a custom file system. If you are running into an issue here then it may suggest that you aren't wrapping or unwrapping correctly. What does Path::getFileSystem return on your Path implementation? -Alan From mik3hall at gmail.com Tue Mar 23 13:47:06 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 23 Mar 2021 08:47:06 -0500 Subject: Why does Path check for the Default FileSystem? In-Reply-To: <8728cbe9-1f41-e759-9412-560ff129c803@oracle.com> References: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> <8728cbe9-1f41-e759-9412-560ff129c803@oracle.com> Message-ID: > On Mar 23, 2021, at 8:41 AM, Alan Bateman wrote: > > On 23/03/2021 13:36, Michael Hall wrote: >> May I ask why the default FileSystem is checked for here? >> >> default File toFile() { >> if (getFileSystem() == FileSystems.getDefault()) { >> return new File(toString()); >> } else { >> throw new UnsupportedOperationException("Path not associated with " >> + "default file system."); >> } >> } >> >> For my custom DefaultFileSystemProvider I found it necessary to have my own Path class. >> Most of mine is passthrough and for the Path class I keep a proxy platform provider Path that I use for almost all functionality. >> This check now seems to fail this? >> Is it necessary to be the default or would also being for the default ?file? scheme be good enough? > A java.io.File cannot represent a file in a custom file system. > > If you are running into an issue here then it may suggest that you aren't wrapping or unwrapping correctly. What does Path::getFileSystem return on your Path implementation? > > -Alan us.hall.trz.osx.MacFileSystem at 4e0e2f2a My own Default one. Maybe custom is the wrong word and means something else. My Default Path class has? @Override public final File toFile() { return proxy.toFile(); } Where proxy is an instance for the same file obtained using the platform provider. The code as-is objects to me falling back to this Path provider. Which effectively makes passthrough impossible. From bpb at openjdk.java.net Tue Mar 23 16:07:40 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 23 Mar 2021 16:07:40 GMT Subject: Integrated: 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists In-Reply-To: References: Message-ID: On Fri, 12 Mar 2021 22:38:05 GMT, Brian Burkhalter wrote: > Please consider this proposal to add `@throws FileAlreadyExistsException` or modify an existing such throws clause's description in a number of methods in `java.nio.file.Files`, `java.nio.file.spi.FileSystemProvider`, and `java.nio.channels.FileChannel`. The methods affected are `open()` in `FileChannel` and various `new*()` methods in `Files` and `FileSystemProvider`. The `Files.newByteChannel()` methods already documented this exception so this would bring the other methods in line. > > A `FileAlreadyExistsException` is an optional specific exception, i.e., a subclass of `IOException` intended to provide a more precise description of the error. The package specification of `java.nio.file` describes optional specific exceptions but those of the other two packages do not. If these exceptions are to be added to the `FileChannel` and `FileSystemProvider` classes, then perhaps a similar paragraph (or a link) should be added to their respective package specifications as well. > > The change to `java.nio.channels.AsynchronousFileChannel` is an incidental correction. This pull request has now been integrated. Changeset: 8fa34e40 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/8fa34e40 Stats: 78 lines in 6 files changed: 64 ins; 0 del; 14 mod 8241619: (fs) Files.newByteChannel(path, Set.of(CREATE_NEW, READ)) does not throw a FileAlreadyExistsException when the file exists Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2980 From Alan.Bateman at oracle.com Tue Mar 23 17:44:38 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Mar 2021 17:44:38 +0000 Subject: Why does Path check for the Default FileSystem? In-Reply-To: References: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> <8728cbe9-1f41-e759-9412-560ff129c803@oracle.com> Message-ID: On 23/03/2021 13:47, Michael Hall wrote: > : > My Default Path class has? > > @Override > public final File toFile() { > return proxy.toFile(); > } > This will delegate to the built-in provider's toFile that will not match the default file system. If you remove the override of toFile then I would expect it should work. -Alan From mik3hall at gmail.com Tue Mar 23 18:57:12 2021 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 23 Mar 2021 13:57:12 -0500 Subject: Why does Path check for the Default FileSystem? In-Reply-To: References: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> <8728cbe9-1f41-e759-9412-560ff129c803@oracle.com> Message-ID: <8B7B6A89-C6A4-4300-BD10-96CBF8680548@gmail.com> > On Mar 23, 2021, at 12:44 PM, Alan Bateman wrote: > > On 23/03/2021 13:47, Michael Hall wrote: >> : >> My Default Path class has? >> >> @Override >> public final File toFile() { >> return proxy.toFile(); >> } >> > This will delegate to the built-in provider's toFile that will not match the default file system. If you remove the override of toFile then I would expect it should work. > > -Alan No, that doesn?t do it either. It seems to get back to the ClassNotFoundException without the jar after getting into the Path code? at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:100) at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:182) at java.base/java.nio.file.Path.of(Path.java:147) at java.base/java.nio.file.Paths.get(Paths.java:69) Verbose class loading similar to before? [0.035s][info][class,load] java.lang.SecurityException source: jrt:/java.base Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" [0.035s][info][class,load] java.lang.Throwable$PrintStreamOrWriter source: jrt:/java.base [0.035s][info][class,load] java.lang.Throwable$WrappedPrintStream source: jrt:/java.base [0.035s][info][class,load] java.util.IdentityHashMap source: shared objects file [0.035s][info][class,load] java.util.IdentityHashMap$KeySet source: shared objects file java.lang.Error: java.lang.ClassNotFoundException: us.hall.trz.osx.MacFileSystemProvider It would be nice if I knew the source of the SecurityException before it percolates out to the strange ClassNotFoundException?s My question as to why does it need to be only the DefaultProvider still remains? That still seems to totally defeat passthrough. https://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html ? Replacing or supplementing the default file system provider. The custom provider can augment the default provider by performing specific operations, such as logging all system operations, and delegate to the default provider for other routine operations. This is what I am trying to do but the code doesn?t seem to allow delegating? -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+741251+turbanoff at openjdk.java.net Tue Mar 23 20:49:46 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Tue, 23 Mar 2021 20:49:46 GMT Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base In-Reply-To: References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> Message-ID: On Tue, 23 Mar 2021 12:38:06 GMT, Pavel Rappo wrote: >> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'` >> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base` >> Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679 > > src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954: > >> 1952: for (int i = 0; i < 4; ++i) { >> 1953: if (i > 0) { >> 1954: sb.append(" "); > > Consider using `String.repeat` here and on L1960 for clarity. I'm not sure how String.repeat can be used here. Repeated String is not constant and different for each iteration. > src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954: > >> 1952: for (int i = 0; i < 4; ++i) { >> 1953: if (i > 0) { >> 1954: sb.append(" "); > > Consider using `String.repeat` here and on L1960 for clarity. I don't think it can be used here. ------------- PR: https://git.openjdk.java.net/jdk/pull/2922 From prappo at openjdk.java.net Tue Mar 23 21:57:39 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 23 Mar 2021 21:57:39 GMT Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base In-Reply-To: References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> Message-ID: On Tue, 23 Mar 2021 20:44:17 GMT, Andrey Turbanov wrote: >> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954: >> >>> 1952: for (int i = 0; i < 4; ++i) { >>> 1953: if (i > 0) { >>> 1954: sb.append(" "); >> >> Consider using `String.repeat` here and on L1960 for clarity. > > I'm not sure how String.repeat can be used here. Repeated String is not constant and different for each iteration. Long runs of whitespace, especially in blank strings, may have poor readability. I was thinking that " ".repeat(7) and " ".repeat(10) might read better than " " and " " respectively. If you don't agree, then simply disregard what I said. If you agree but worry about negative performance implications, consider creating these strings before the respective for-loops. ------------- PR: https://git.openjdk.java.net/jdk/pull/2922 From brian.burkhalter at oracle.com Wed Mar 24 00:42:13 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Mar 2021 17:42:13 -0700 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> References: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> Message-ID: <7A307119-9CA2-4CBB-AA06-5CC7DC27C777@oracle.com> > On Mar 10, 2021, at 9:23 AM, Sebastian Stenzel wrote: > > Is there no way to review increments? After all, JDK-8262958 addresses several related tasks. All we would need is a way to review individual commits instead of the PR as a whole. > > But yes, we certainly can subdivide it further: I'd need you to replace JDK-8262958 by a three more issues: > > 1. Deduplicate code around `flistxattr` calls inside of UnixUserDefinedFileAttributeView.java Perhaps JDK-8262958 can be revised to cover only this #1 as no PR has yet been filed? > 2. Fix UnsupportedOperationException when passing a ByteBuffer without a backing array to `UnixUserDefinedFileAttributeView.read(String name, ByteBuffer dst)` > 3. Use try-with-resource for all NativeBuffers within UnixUserDefinedFileAttributeView, fixing leak when opening a file for read/write attr fails (in lines [1] and [2]) > 4. Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java Sebastian, do you have JBS access yet so that you could file these other three? Also there was mentioned in the PR [A] for [B] about filing another issue for the close(-1) case. [A] https://github.com/openjdk/jdk/pull/2816#discussion_r587801192 [B] https://bugs.openjdk.java.net/browse/JDK-8262957 > [1]: https://github.com/openjdk/jdk/blob/7e52a6e8b37412b43b0024ca067959100c14f508/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L187 > [2]: https://github.com/openjdk/jdk/blob/7e52a6e8b37412b43b0024ca067959100c14f508/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L258 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.stenzel at gmail.com Wed Mar 24 08:24:43 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 24 Mar 2021 09:24:43 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: <7A307119-9CA2-4CBB-AA06-5CC7DC27C777@oracle.com> References: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> <7A307119-9CA2-4CBB-AA06-5CC7DC27C777@oracle.com> Message-ID: > On 24. Mar 2021, at 01:42, Brian Burkhalter wrote: > > >> On Mar 10, 2021, at 9:23 AM, Sebastian Stenzel > wrote: >> >> Is there no way to review increments? After all, JDK-8262958 addresses several related tasks. All we would need is a way to review individual commits instead of the PR as a whole. >> >> But yes, we certainly can subdivide it further: I'd need you to replace JDK-8262958 by a three more issues: >> >> 1. Deduplicate code around `flistxattr` calls inside of UnixUserDefinedFileAttributeView.java > > Perhaps JDK-8262958 can be revised to cover only this #1 as no PR has yet been filed? > >> 2. Fix UnsupportedOperationException when passing a ByteBuffer without a backing array to `UnixUserDefinedFileAttributeView.read(String name, ByteBuffer dst)` >> 3. Use try-with-resource for all NativeBuffers within UnixUserDefinedFileAttributeView, fixing leak when opening a file for read/write attr fails (in lines [1] and [2]) >> 4. Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java > > Sebastian, do you have JBS access yet so that you could file these other three? Also there was mentioned in the PR [A] for [B] about filing another issue for the close(-1) case. > > [A] https://github.com/openjdk/jdk/pull/2816#discussion_r587801192 > [B] https://bugs.openjdk.java.net/browse/JDK-8262957 Yes, I was granted access rights and will deal with creation of the discussed issues and change the scope of JDK-8262958 as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+1204330+overheadhunter at openjdk.java.net Wed Mar 24 08:39:38 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Wed, 24 Mar 2021 08:39:38 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: References: <3oC7RYLaLrQGrEdqrGV9oSIs_hQbY8GVuVg9SL9_v1M=.d809d1cf-9474-4177-a008-773c69f60354@github.com> <5zypJQRKllJ-CTbg2rNjwyOwWx1bEnc24dbszBCDsNc=.716bd821-0e38-4252-85d7-eeb8907446af@github.com> Message-ID: On Fri, 5 Mar 2021 06:51:29 GMT, Sebastian Stenzel wrote: >> It's somewhat subjective. What you have is fine, I just would have done is differently to avoid too many return paths. >> >> I think we should clean up the close(-1) case while we are in the area, separate PR of course. > > All right, will you create another bug report for the `close(-1)` issue? I just wanted to create another issue, but then I noticed that `close(-1)` is allowed as per contract: https://github.com/openjdk/jdk/blob/45e1bab87ccebd498d4f927a008dd89a47dd177b/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java#L90-L97 We can still change this, of course, but I wouldn't consider this a necessary change for this PR and would therefore suggest to deal with this another time. ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From Alan.Bateman at oracle.com Wed Mar 24 08:49:32 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Mar 2021 08:49:32 +0000 Subject: Why does Path check for the Default FileSystem? In-Reply-To: <8B7B6A89-C6A4-4300-BD10-96CBF8680548@gmail.com> References: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> <8728cbe9-1f41-e759-9412-560ff129c803@oracle.com> <8B7B6A89-C6A4-4300-BD10-96CBF8680548@gmail.com> Message-ID: On 23/03/2021 18:57, Michael Hall wrote: > : > > No, that doesn?t do it either. It seems to get back to the > ClassNotFoundException without the jar after getting into the Path code? > > at > java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133) > at > java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102) > at > java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100) > at > java.base/java.security.AccessController.doPrivileged(AccessController.java:312) > at > java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:100) > at > java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) > at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:182) > at java.base/java.nio.file.Path.of(Path.java:147) > at java.base/java.nio.file.Paths.get(Paths.java:69) > > Verbose class loading similar to before? > > [0.035s][info][class,load] java.lang.SecurityException source: > jrt:/java.base > Error: A JNI error has occurred, please check your installation and > try again > Exception in thread "main" [0.035s][info][class,load] > java.lang.Throwable$PrintStreamOrWriter source: jrt:/java.base > [0.035s][info][class,load] java.lang.Throwable$WrappedPrintStream > source: jrt:/java.base > [0.035s][info][class,load] java.util.IdentityHashMap source: shared > objects file > [0.035s][info][class,load] java.util.IdentityHashMap$KeySet source: > shared objects file > java.lang.Error: java.lang.ClassNotFoundException: > us.hall.trz.osx.MacFileSystemProvider > > It would be nice if I knew the source of the SecurityException before > it percolates out to the strange ClassNotFoundException?s > > My question as to why does it need to be only the DefaultProvider > still remains? That still seems to totally defeat passthrough. > > https://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html > > ? Replacing or supplementing the default file system provider. The > custom provider can augment the default provider by performing > specific operations,?such as logging all system operations, and > delegate to the default provider for other routine operations. > > This is what I am trying to do but the code doesn?t seem to allow > delegating? > I just tried the TestProvider that we have in the test tree and it works as the default file system provider when exploded on the file system (not packaged as a JAR file on the class path as thee is an issue there). I commented out the override of toFile() and it does the right thing. So I'm not 100% sure how you are running into an issue, I think we need something that reproduces it. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.java.net Wed Mar 24 08:49:41 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 24 Mar 2021 08:49:41 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: References: <3oC7RYLaLrQGrEdqrGV9oSIs_hQbY8GVuVg9SL9_v1M=.d809d1cf-9474-4177-a008-773c69f60354@github.com> <5zypJQRKllJ-CTbg2rNjwyOwWx1bEnc24dbszBCDsNc=.716bd821-0e38-4252-85d7-eeb8907446af@github.com> Message-ID: On Wed, 24 Mar 2021 08:35:45 GMT, Sebastian Stenzel wrote: >> All right, will you create another bug report for the `close(-1)` issue? > > I just wanted to create another issue, but then I noticed that `close(-1)` is allowed as per contract: https://github.com/openjdk/jdk/blob/45e1bab87ccebd498d4f927a008dd89a47dd177b/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java#L90-L97 > > We can still change this, of course, but I wouldn't consider this a necessary change for this PR and would therefore suggest to deal with this another time. Okay, I had forgotten that that UnixNativeDispatcher.close(-1) is a no-op. ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From sebastian.stenzel at gmail.com Wed Mar 24 08:57:47 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 24 Mar 2021 09:57:47 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: References: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> <7A307119-9CA2-4CBB-AA06-5CC7DC27C777@oracle.com> Message-ID: <5FA28A55-258E-44AF-BC12-33D9BB95B1AD@gmail.com> > On 24. Mar 2021, at 09:24, Sebastian Stenzel wrote: > >> On 24. Mar 2021, at 01:42, Brian Burkhalter > wrote: >> >> >>> On Mar 10, 2021, at 9:23 AM, Sebastian Stenzel > wrote: >>> >>> Is there no way to review increments? After all, JDK-8262958 addresses several related tasks. All we would need is a way to review individual commits instead of the PR as a whole. >>> >>> But yes, we certainly can subdivide it further: I'd need you to replace JDK-8262958 by a three more issues: >>> >>> 1. Deduplicate code around `flistxattr` calls inside of UnixUserDefinedFileAttributeView.java >> >> Perhaps JDK-8262958 can be revised to cover only this #1 as no PR has yet been filed? >> >>> 2. Fix UnsupportedOperationException when passing a ByteBuffer without a backing array to `UnixUserDefinedFileAttributeView.read(String name, ByteBuffer dst)` >>> 3. Use try-with-resource for all NativeBuffers within UnixUserDefinedFileAttributeView, fixing leak when opening a file for read/write attr fails (in lines [1] and [2]) >>> 4. Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java >> >> Sebastian, do you have JBS access yet so that you could file these other three? Also there was mentioned in the PR [A] for [B] about filing another issue for the close(-1) case. >> >> [A] https://github.com/openjdk/jdk/pull/2816#discussion_r587801192 >> [B] https://bugs.openjdk.java.net/browse/JDK-8262957 > > Yes, I was granted access rights and will deal with creation of the discussed issues and change the scope of JDK-8262958 as well. > I changed JDK-8262958's description. Should I update the title as well, or will that confuse the bots dealing with the existing PR? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian.stenzel at gmail.com Wed Mar 24 09:29:03 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Wed, 24 Mar 2021 10:29:03 +0100 Subject: Further UserDefinedFileAttributeView improvements and fixes In-Reply-To: <5FA28A55-258E-44AF-BC12-33D9BB95B1AD@gmail.com> References: <86ff11ea-2687-d7a5-63b3-3934c9ba8a6d@oracle.com> <9420A8C0-B9B9-450D-8612-AD4068F9CA6F@gmail.com> <8475D24A-7389-4CC3-A38A-D196D6A3B6F1@gmail.com> <7A307119-9CA2-4CBB-AA06-5CC7DC27C777@oracle.com> <5FA28A55-258E-44AF-BC12-33D9BB95B1AD@gmail.com> Message-ID: > On 24. Mar 2021, at 09:57, Sebastian Stenzel wrote: > >> On 24. Mar 2021, at 09:24, Sebastian Stenzel > wrote: >> >>> On 24. Mar 2021, at 01:42, Brian Burkhalter > wrote: >>> >>> >>>> On Mar 10, 2021, at 9:23 AM, Sebastian Stenzel > wrote: >>>> >>>> Is there no way to review increments? After all, JDK-8262958 addresses several related tasks. All we would need is a way to review individual commits instead of the PR as a whole. >>>> >>>> But yes, we certainly can subdivide it further: I'd need you to replace JDK-8262958 by a three more issues: >>>> >>>> 1. Deduplicate code around `flistxattr` calls inside of UnixUserDefinedFileAttributeView.java >>> >>> Perhaps JDK-8262958 can be revised to cover only this #1 as no PR has yet been filed? >>> >>>> 2. Fix UnsupportedOperationException when passing a ByteBuffer without a backing array to `UnixUserDefinedFileAttributeView.read(String name, ByteBuffer dst)` >>>> 3. Use try-with-resource for all NativeBuffers within UnixUserDefinedFileAttributeView, fixing leak when opening a file for read/write attr fails (in lines [1] and [2]) >>>> 4. Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java For 2. - 4. I've files issues JDK-8264110, JDK-8264111, JDK-8264112 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Wed Mar 24 10:35:11 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 24 Mar 2021 05:35:11 -0500 Subject: Why does Path check for the Default FileSystem? In-Reply-To: References: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> <8728cbe9-1f41-e759-9412-560ff129c803@oracle.com> <8B7B6A89-C6A4-4300-BD10-96CBF8680548@gmail.com> Message-ID: <28B16352-1DEE-410E-A4D3-5A99301A021F@gmail.com> > On Mar 24, 2021, at 3:49 AM, Alan Bateman wrote: > > On 23/03/2021 18:57, Michael Hall wrote: >> : >> >> No, that doesn?t do it either. It seems to get back to the ClassNotFoundException without the jar after getting into the Path code? >> >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100) >> at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:100) >> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) >> at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:182) >> at java.base/java.nio.file.Path.of(Path.java:147) >> at java.base/java.nio.file.Paths.get(Paths.java:69) >> >> Verbose class loading similar to before? >> >> [0.035s][info][class,load] java.lang.SecurityException source: jrt:/java.base >> Error: A JNI error has occurred, please check your installation and try again >> Exception in thread "main" [0.035s][info][class,load] java.lang.Throwable$PrintStreamOrWriter source: jrt:/java.base >> [0.035s][info][class,load] java.lang.Throwable$WrappedPrintStream source: jrt:/java.base >> [0.035s][info][class,load] java.util.IdentityHashMap source: shared objects file >> [0.035s][info][class,load] java.util.IdentityHashMap$KeySet source: shared objects file >> java.lang.Error: java.lang.ClassNotFoundException: us.hall.trz.osx.MacFileSystemProvider >> >> It would be nice if I knew the source of the SecurityException before it percolates out to the strange ClassNotFoundException?s >> >> My question as to why does it need to be only the DefaultProvider still remains? That still seems to totally defeat passthrough. >> >> https://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html >> ? Replacing or supplementing the default file system provider. The custom provider can augment the default provider by performing specific operations, such as logging all system operations, and delegate to the default provider for other routine operations. >> >> This is what I am trying to do but the code doesn?t seem to allow delegating? >> > I just tried the TestProvider that we have in the test tree and it works as the default file system provider when exploded on the file system (not packaged as a JAR file on the class path as thee is an issue there). I commented out the override of toFile() and it does the right thing. So I'm not 100% sure how you are running into an issue, I think we need something that reproduces it. > > -Alan I will try to look at it some more today but I do seem to be running into more problems. I tried modular jar, not sure if correctly, and it was the same situation. It wouldn?t work unless the classes are also exploded. Exploded I run into the Path toFile error. I am working with a test class written against my old provider. But if I can?t get anywhere there I can try to reproduce with the zip you included with the bug report. -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+1204330+overheadhunter at openjdk.java.net Wed Mar 24 11:11:48 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Wed, 24 Mar 2021 11:11:48 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write Message-ID: Added new private methods for `read(String name, long address, int rem)` and `write(String name, long address, int rem)` that take an address as an argument and thereby no longer need to deal with any NativeBuffers. This allows a certain simplification of `read(String name, ByteBuffer dst)` and `write(String name, ByteBuffer src)` and use of `try (NativeBuffer nb = NativeBuffers.getNativeBuffer(rem)) {...}` which fixes the issue. ------------- Commit messages: - refactor read and write to use try-with-resource for NativeBuffer Changes: https://git.openjdk.java.net/jdk/pull/3171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264111 Stats: 86 lines in 1 file changed: 24 ins; 27 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/3171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3171/head:pull/3171 PR: https://git.openjdk.java.net/jdk/pull/3171 From mik3hall at gmail.com Wed Mar 24 11:43:04 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 24 Mar 2021 06:43:04 -0500 Subject: Why does Path check for the Default FileSystem? In-Reply-To: <28B16352-1DEE-410E-A4D3-5A99301A021F@gmail.com> References: <587D2F18-5A20-4E91-8B1D-92C033BD518E@gmail.com> <8728cbe9-1f41-e759-9412-560ff129c803@oracle.com> <8B7B6A89-C6A4-4300-BD10-96CBF8680548@gmail.com> <28B16352-1DEE-410E-A4D3-5A99301A021F@gmail.com> Message-ID: <60A4DC17-B1B0-4293-9504-AE09032AE992@gmail.com> > On Mar 24, 2021, at 5:35 AM, Michael Hall wrote: > > > >> On Mar 24, 2021, at 3:49 AM, Alan Bateman > wrote: >> >> On 23/03/2021 18:57, Michael Hall wrote: >>> : >>> >>> No, that doesn?t do it either. It seems to get back to the ClassNotFoundException without the jar after getting into the Path code? >>> >>> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.getDefaultProvider(FileSystems.java:133) >>> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:102) >>> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder$1.run(FileSystems.java:100) >>> at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) >>> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.defaultFileSystem(FileSystems.java:100) >>> at java.base/java.nio.file.FileSystems$DefaultFileSystemHolder.(FileSystems.java:94) >>> at java.base/java.nio.file.FileSystems.getDefault(FileSystems.java:182) >>> at java.base/java.nio.file.Path.of(Path.java:147) >>> at java.base/java.nio.file.Paths.get(Paths.java:69) >>> >>> Verbose class loading similar to before? >>> >>> [0.035s][info][class,load] java.lang.SecurityException source: jrt:/java.base >>> Error: A JNI error has occurred, please check your installation and try again >>> Exception in thread "main" [0.035s][info][class,load] java.lang.Throwable$PrintStreamOrWriter source: jrt:/java.base >>> [0.035s][info][class,load] java.lang.Throwable$WrappedPrintStream source: jrt:/java.base >>> [0.035s][info][class,load] java.util.IdentityHashMap source: shared objects file >>> [0.035s][info][class,load] java.util.IdentityHashMap$KeySet source: shared objects file >>> java.lang.Error: java.lang.ClassNotFoundException: us.hall.trz.osx.MacFileSystemProvider >>> >>> It would be nice if I knew the source of the SecurityException before it percolates out to the strange ClassNotFoundException?s >>> >>> My question as to why does it need to be only the DefaultProvider still remains? That still seems to totally defeat passthrough. >>> >>> https://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html >>> ? Replacing or supplementing the default file system provider. The custom provider can augment the default provider by performing specific operations, such as logging all system operations, and delegate to the default provider for other routine operations. >>> >>> This is what I am trying to do but the code doesn?t seem to allow delegating? >>> >> I just tried the TestProvider that we have in the test tree and it works as the default file system provider when exploded on the file system (not packaged as a JAR file on the class path as thee is an issue there). I commented out the override of toFile() and it does the right thing. So I'm not 100% sure how you are running into an issue, I think we need something that reproduces it. >> >> -Alan > > I will try to look at it some more today but I do seem to be running into more problems. I tried modular jar, not sure if correctly, and it was the same situation. It wouldn?t work unless the classes are also exploded. Exploded I run into the Path toFile error. I am working with a test class written against my old provider. But if I can?t get anywhere there I can try to reproduce with the zip you included with the bug report. > More luck this morning. Commented out the toFile again and it worked. Exploded, supposedly modular jar, no luck unexploded. I looked at Path itself and toFile seems to be the only method that includes the required Default check. I still think that check would need to be used carefully or people could have problems with passthrough. My own Path implementation really seems to serve no useful purpose. I vaguely remember that something required me to have one, but I made as best as possible everything passthrough. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Wed Mar 24 14:06:09 2021 From: mik3hall at gmail.com (Michael Hall) Date: Wed, 24 Mar 2021 09:06:09 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> Message-ID: For some or all cases where it fails FileSystems.java private static FileSystemProvider getDefaultProvider() { Fails to load the class. I have been unable in testing to get the cut and pasted method to load it either. It never gets the Class. Double checking the bug report seems to show that jar or modular jar are the only not exploded options(?) I was hoping for a workaround that didn?t require exploded but for now I guess I?ll settle for that. > > >> to compile code that uses it). It it encapsulated at run-time since Java 16. Many of the features that eio.FileManager provided are superseded by standard APIs and java.awt.Desktop. My understanding is that type/creator codes are legacy and have been ignored on macOS for 10 years > You may be right here. Path defApp = (Path)Files.getAttribute(p,"mac_ls:default_application"); System.out.println("default " + defApp); int i_type = FileManager.OSTypeToInt("TEXT"); int i_creator = FileManager.OSTypeToInt("ttxt"); FileManager.setFileTypeAndCreator(p.toString(),i_type,i_creator); defApp = (Path)Files.getAttribute(p,"mac_ls:default_application"); System.out.println("new default " + defApp); Gets? default /Applications/BBEdit.app new default /Applications/BBEdit.app For TEXT/ttxt I expected it to change the default application to TextEdit. It didn?t. For added value for my FileManager replacement I also came up with a FileHelper class that included some code related to the nio attributes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at openjdk.java.net Wed Mar 24 18:14:49 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 24 Mar 2021 18:14:49 GMT Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in java.base In-Reply-To: References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> Message-ID: On Tue, 23 Mar 2021 21:54:33 GMT, Pavel Rappo wrote: >> I'm not sure how String.repeat can be used here. Repeated String is not constant and different for each iteration. > > Long runs of whitespace, especially in blank strings, may have poor readability. I was thinking that > > " ".repeat(7) and " ".repeat(10) > > > might read better than > > " " and " " > > respectively. If you don't agree, then simply disregard what I said. If you agree but worry about negative performance implications, consider creating these strings before the respective for-loops. I suggest we ignore the use case for `String.repeat` here, and leave the patch as is. ------------- PR: https://git.openjdk.java.net/jdk/pull/2922 From github.com+782446+simon04 at openjdk.java.net Wed Mar 24 23:31:52 2021 From: github.com+782446+simon04 at openjdk.java.net (Simon Legner) Date: Wed, 24 Mar 2021 23:31:52 GMT Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException Message-ID: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException ------------- Commit messages: - ZipFileSystem: fix typo in ZipException Changes: https://git.openjdk.java.net/jdk/pull/2588/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2588&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264031 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2588.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2588/head:pull/2588 PR: https://git.openjdk.java.net/jdk/pull/2588 From shade at openjdk.java.net Wed Mar 24 23:31:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 24 Mar 2021 23:31:52 GMT Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException In-Reply-To: References: Message-ID: <1LnH8R14r589cROzzn8xPopc22rSVOGPy5OBKwlQDZA=.73fa4a36-0e0b-46d3-bd6c-ddda8d55df92@github.com> On Tue, 16 Feb 2021 13:48:20 GMT, Simon Legner wrote: > 8264031: Fix typo in ZipFileSystem.deleteFile ZipException This looks good to me. Are you willing to continue with this PR? I see that OCA is still pending. I have created the bug for this issue: https://bugs.openjdk.java.net/browse/JDK-8264031 -- please change PR synopsis to "8264031: Fix typo in ZipFileSystem.deleteFile ZipException" to get it hooked appropriately. ------------- PR: https://git.openjdk.java.net/jdk/pull/2588 From bpb at openjdk.java.net Wed Mar 24 23:49:56 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 24 Mar 2021 23:49:56 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) Message-ID: This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. ------------- Commit messages: - 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) Changes: https://git.openjdk.java.net/jdk/pull/3183/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263898 Stats: 53 lines in 2 files changed: 50 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3183/head:pull/3183 PR: https://git.openjdk.java.net/jdk/pull/3183 From shade at openjdk.java.net Thu Mar 25 06:16:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 25 Mar 2021 06:16:39 GMT Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 13:48:20 GMT, Simon Legner wrote: > 8264031: Fix typo in ZipFileSystem.deleteFile ZipException Looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2588 From shade at openjdk.java.net Thu Mar 25 06:16:39 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 25 Mar 2021 06:16:39 GMT Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 06:13:28 GMT, Aleksey Shipilev wrote: >> 8264031: Fix typo in ZipFileSystem.deleteFile ZipException > > Looks fine to me. Note that the PR synopsis should now match the bug title, as bot says in "Integration Blocker". I think "(zipfs)" is missing. ------------- PR: https://git.openjdk.java.net/jdk/pull/2588 From alanb at openjdk.java.net Thu Mar 25 07:37:40 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 25 Mar 2021 07:37:40 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 23:45:16 GMT, Brian Burkhalter wrote: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 533: > 531: } > 532: } > 533: } The native methods are meant to map to one win32 call where possible. In this case, I think the workaround needs to be in WindowsChannelFile.open. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From jpai at openjdk.java.net Thu Mar 25 08:05:51 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Thu, 25 Mar 2021 08:05:51 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) In-Reply-To: References: Message-ID: <-TbVI5Di_GmBsSIs2DgdCeS53MkWHAwA9s3ipOchgO4=.a38d4082-b6f0-4fc7-b419-31a9870aa2c9@github.com> On Wed, 24 Mar 2021 23:45:16 GMT, Brian Burkhalter wrote: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. test/jdk/java/nio/file/Files/NullDevice.java line 34: > 32: * @run main NullDevice > 33: */ > 34: public class NullDevice { Hello Brian, Given what's being tested here, perhaps this test should only be run against Windows OS? So maybe something like `@requires os.name=="windows"`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From lancea at openjdk.java.net Thu Mar 25 10:43:52 2021 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 25 Mar 2021 10:43:52 GMT Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException In-Reply-To: References: Message-ID: On Tue, 16 Feb 2021 13:48:20 GMT, Simon Legner wrote: > 8264031: Fix typo in ZipFileSystem.deleteFile ZipException Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2588 From Alan.Bateman at oracle.com Thu Mar 25 11:40:30 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Mar 2021 11:40:30 +0000 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> Message-ID: <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> On 24/03/2021 14:06, Michael Hall wrote: > : > > Double checking the bug report seems to show that jar or modular jar > are the only not exploded options(?) I was hoping for a workaround > that didn?t require exploded but for now I guess I?ll settle for that. > I think the bug is specified to the case that the default file system provider is deployed in a JAR file on the class path. Hopefully that will be fixed soon. The other cases, where the default file system provider is exploded on the class path, or deployed as a module on the module path (exploded or modular JAR) should not be impacted by the bug. -Alan From alanb at openjdk.java.net Thu Mar 25 11:40:39 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 25 Mar 2021 11:40:39 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 10:37:56 GMT, Sebastian Stenzel wrote: > Added new private methods for `read(String name, long address, int rem)` and `write(String name, long address, int rem)` that take an address as an argument and thereby no longer need to deal with any NativeBuffers. > > This allows a certain simplification of `read(String name, ByteBuffer dst)` and `write(String name, ByteBuffer src)` and use of `try (NativeBuffer nb = NativeBuffers.getNativeBuffer(rem)) {...}` which fixes the issue. This looks good. Would you mind adding "@Override" to the public write method so it is consistent with the other public methods. src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 174: > 172: if (dst instanceof sun.nio.ch.DirectBuffer buf) { > 173: long address = buf.address() + pos; > 174: int n = read(name, address, rem); We need to add reachabilityFence here, don't mind if we do it now while changing this code or later. That is, it should be try { n = read(name, address, rem); } finally { Reference.reachabilityFence(buf); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3171 From github.com+1204330+overheadhunter at openjdk.java.net Thu Mar 25 11:57:56 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Thu, 25 Mar 2021 11:57:56 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write [v2] In-Reply-To: References: Message-ID: > Added new private methods for `read(String name, long address, int rem)` and `write(String name, long address, int rem)` that take an address as an argument and thereby no longer need to deal with any NativeBuffers. > > This allows a certain simplification of `read(String name, ByteBuffer dst)` and `write(String name, ByteBuffer src)` and use of `try (NativeBuffer nb = NativeBuffers.getNativeBuffer(rem)) {...}` which fixes the issue. Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: Added @Override annotation to write(String, ByteBuffer) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3171/files - new: https://git.openjdk.java.net/jdk/pull/3171/files/50e13d31..d3cb759b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3171&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3171&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3171/head:pull/3171 PR: https://git.openjdk.java.net/jdk/pull/3171 From github.com+1204330+overheadhunter at openjdk.java.net Thu Mar 25 11:57:57 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Thu, 25 Mar 2021 11:57:57 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write [v2] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 11:35:51 GMT, Alan Bateman wrote: >> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: >> >> Added @Override annotation to write(String, ByteBuffer) > > src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 174: > >> 172: if (dst instanceof sun.nio.ch.DirectBuffer buf) { >> 173: long address = buf.address() + pos; >> 174: int n = read(name, address, rem); > > We need to add reachabilityFence here, don't mind if we do it now while changing this code or later. > That is, it should be try { n = read(name, address, rem); } finally { Reference.reachabilityFence(buf); } Never heard of this before, just read the docs the first time. Do I get this right, that this helps to protect against instant finalization of the buffer in e.g. `attrView.read("foo", ByteBuffer.allocateDirect(42))`? What about the `write` case? ------------- PR: https://git.openjdk.java.net/jdk/pull/3171 From mik3hall at gmail.com Thu Mar 25 12:20:41 2021 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 25 Mar 2021 07:20:41 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> Message-ID: <87BB5333-F466-4450-B8AC-208B0832DBCE@gmail.com> > On Mar 25, 2021, at 6:40 AM, Alan Bateman wrote: > > On 24/03/2021 14:06, Michael Hall wrote: >> : >> >> Double checking the bug report seems to show that jar or modular jar are the only not exploded options(?) I was hoping for a workaround that didn?t require exploded but for now I guess I?ll settle for that. >> > I think the bug is specified to the case that the default file system provider is deployed in a JAR file on the class path. Hopefully that will be fixed soon. The other cases, where the default file system provider is exploded on the class path, or deployed as a module on the module path (exploded or modular JAR) should not be impacted by the bug. > > -Alan It seemed to occur for me with a modular jar. But I haven?t done anything modular yet so may not of done it correctly. I will look further into the test cases you indicated. Otherwise I will watch the bug for resolution. Thanks again for the time. From bpb at openjdk.java.net Thu Mar 25 15:28:28 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Mar 2021 15:28:28 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 07:35:11 GMT, Alan Bateman wrote: >> This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. > > src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 533: > >> 531: } >> 532: } >> 533: } > > The native methods are meant to map to one win32 call where possible. In this case, I think the workaround needs to be in WindowsChannelFile.open. I know. I tried at the Java level first and one cannot verify the size of the NUL device from Java. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Thu Mar 25 15:28:32 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Mar 2021 15:28:32 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) In-Reply-To: <-TbVI5Di_GmBsSIs2DgdCeS53MkWHAwA9s3ipOchgO4=.a38d4082-b6f0-4fc7-b419-31a9870aa2c9@github.com> References: <-TbVI5Di_GmBsSIs2DgdCeS53MkWHAwA9s3ipOchgO4=.a38d4082-b6f0-4fc7-b419-31a9870aa2c9@github.com> Message-ID: On Thu, 25 Mar 2021 08:03:02 GMT, Jaikiran Pai wrote: >> This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. > > test/jdk/java/nio/file/Files/NullDevice.java line 34: > >> 32: * @run main NullDevice >> 33: */ >> 34: public class NullDevice { > > Hello Brian, > > Given what's being tested here, perhaps this test should only be run against Windows OS? So maybe something like `@requires os.family=="windows"`? You are correct, I intended to but forgot to add that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Thu Mar 25 15:34:34 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Mar 2021 15:34:34 GMT Subject: RFR: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced [v6] In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 15:14:51 GMT, lyndseyBeil wrote: >> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge >> - 4833719: corrections pursuant to JDK-8263742 >> - 4833719: Corrected faux pas in correcting faux pas >> - 4833719: Corrected faux pas in the slice(int,int) spec >> - 4833719: Remove @apiNotes and "A similar consideration" >> - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced > > test/jdk/java/nio/MappedByteBuffer/ForceViews.java line 48: > >> 46: public class ForceViews { >> 47: >> 48: static record Segment(int position, int length) {} > > I detect that this code is problematic. According to the [Bad practice (BAD_PRACTICE)](https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#bad-practice-bad-practice), [Nm: Method names should start with a lower case letter (NM_METHOD_NAMING_CONVENTION)](https://spotbugs.readthedocs.io/en/stable/bugDescriptions.html#nm-method-names-should-start-with-a-lower-case-letter-nm-method-naming-convention). > Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized. `Segment` is a `record`, not a method (cf. https://openjdk.java.net/jeps/395). ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From bpb at openjdk.java.net Thu Mar 25 15:34:37 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Mar 2021 15:34:37 GMT Subject: Integrated: 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced In-Reply-To: References: Message-ID: On Tue, 9 Mar 2021 22:20:52 GMT, Brian Burkhalter wrote: > Please consider this proposal to add covariant overrides to `MappedByteBuffer` for the methods `compact()`, `duplicate()`, `slice()`, and `slice(int,int)`. > > The methods in question are added as abstract specifications in `MappedByteBuffer` and their implementations in `Direct-X-Buffer.java.template`. In `MappedByteBuffer` the `isSync()` method is changed to have package access, and a final package scope method `FileDescriptor fileDescriptor()` is added to return the associated file descriptor. Specification verbiage is added to the new covariant overrides, and the specification of `force()` is enhanced slightly. (The `unmapper()` method offers an alternative way to obtain the file descriptor and sync mode without the need for package access `fileDescriptor()` and `isSync()` methods.) > > In `Direct-X-Buffer.java.template` the constructor for duplicates and slices is modified to accept parameters for the file descriptor and sync mode for byte buffers. The uses of this constructor are correspondingly modified. > > A test is added to exercise the new methods. Verifying that `force()` is actually doing anything is not verified by this test but was checked manually. The change passes all other existing tests in tiers 1-3. > > Other methods for which it might be worth adding covariant overrides are the `get()` and `put()` methods which return a buffer, and, less interesting, the `put$Type$()` methods. This pull request has now been integrated. Changeset: b006f22f Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/b006f22f Stats: 214 lines in 3 files changed: 201 ins; 0 del; 13 mod 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced Reviewed-by: adinn ------------- PR: https://git.openjdk.java.net/jdk/pull/2902 From alanb at openjdk.java.net Thu Mar 25 15:35:29 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 25 Mar 2021 15:35:29 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 15:24:42 GMT, Brian Burkhalter wrote: >> src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 533: >> >>> 531: } >>> 532: } >>> 533: } >> >> The native methods are meant to map to one win32 call where possible. In this case, I think the workaround needs to be in WindowsChannelFile.open. > > I know. I tried at the Java level first and one cannot verify the size of the NUL device from Java. it's okay to add a new method to WindowsNativeDispatcher if we need it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Thu Mar 25 18:40:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Mar 2021 18:40:43 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v2] In-Reply-To: References: Message-ID: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: Add GetFileSizeEx() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3183/files - new: https://git.openjdk.java.net/jdk/pull/3183/files/34146154..6a290dfd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=00-01 Stats: 35 lines in 4 files changed: 26 ins; 6 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3183/head:pull/3183 PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Thu Mar 25 18:40:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Mar 2021 18:40:43 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v2] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 15:32:26 GMT, Alan Bateman wrote: >> I know. I tried at the Java level first and one cannot verify the size of the NUL device from Java. > > it's okay to add a new method to WindowsNativeDispatcher if we need it. Added `GetFileSizeEx()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Thu Mar 25 18:40:44 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Mar 2021 18:40:44 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v2] In-Reply-To: References: <-TbVI5Di_GmBsSIs2DgdCeS53MkWHAwA9s3ipOchgO4=.a38d4082-b6f0-4fc7-b419-31a9870aa2c9@github.com> Message-ID: On Thu, 25 Mar 2021 15:25:06 GMT, Brian Burkhalter wrote: >> test/jdk/java/nio/file/Files/NullDevice.java line 34: >> >>> 32: * @run main NullDevice >>> 33: */ >>> 34: public class NullDevice { >> >> Hello Brian, >> >> Given what's being tested here, perhaps this test should only be run against Windows OS? So maybe something like `@requires os.family=="windows"`? > > You are correct, I intended to but forgot to add that. Added suggested `@requires`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Thu Mar 25 22:16:46 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 25 Mar 2021 22:16:46 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v3] In-Reply-To: References: Message-ID: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: Remove whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3183/files - new: https://git.openjdk.java.net/jdk/pull/3183/files/6a290dfd..8389cda0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3183/head:pull/3183 PR: https://git.openjdk.java.net/jdk/pull/3183 From jpai at openjdk.java.net Fri Mar 26 01:19:26 2021 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 26 Mar 2021 01:19:26 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v3] In-Reply-To: References: Message-ID: <_6flSILtpbkRtk8l8uZbiEKCnrzHDaQ-EpYni8QZv7E=.4b2de221-5aa5-44b0-b5f0-3d1ca67bb91b@github.com> On Thu, 25 Mar 2021 22:16:46 GMT, Brian Burkhalter wrote: >> This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > Remove whitespace The test case (changes) looks fine to me. Thank you Brian. ------------- Marked as reviewed by jpai (Committer). PR: https://git.openjdk.java.net/jdk/pull/3183 From mik3hall at gmail.com Fri Mar 26 02:25:30 2021 From: mik3hall at gmail.com (Michael Hall) Date: Thu, 25 Mar 2021 21:25:30 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <87BB5333-F466-4450-B8AC-208B0832DBCE@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> <87BB5333-F466-4450-B8AC-208B0832DBCE@gmail.com> Message-ID: <82C800B3-F6DD-4E62-953D-94BF5E2A74B7@gmail.com> > On Mar 25, 2021, at 7:20 AM, Michael Hall wrote: > > > >> On Mar 25, 2021, at 6:40 AM, Alan Bateman wrote: >> >> On 24/03/2021 14:06, Michael Hall wrote: >>> : >>> >>> Double checking the bug report seems to show that jar or modular jar are the only not exploded options(?) I was hoping for a workaround that didn?t require exploded but for now I guess I?ll settle for that. >>> >> I think the bug is specified to the case that the default file system provider is deployed in a JAR file on the class path. Hopefully that will be fixed soon. The other cases, where the default file system provider is exploded on the class path, or deployed as a module on the module path (exploded or modular JAR) should not be impacted by the bug. >> >> -Alan > > It seemed to occur for me with a modular jar. But I haven?t done anything modular yet so may not of done it correctly. I will look further into the test cases you indicated. Otherwise I will watch the bug for resolution. > > Thanks again for the time. Possibly of additional interest. Partly out of curiosity and partly because I often test from there I tried to make my default FileSystemProvider available to an OS/X application. I modified the .cfg file to include the -Djava.nio.file.spi.DefaultFileSystemProvider parm, added $APPDIR as a class path entry, and included the exploded classes. Starting up includes a console that shows the error... Caused by: java.lang.ClassCastException: class us.hall.trz.osx.MacPath cannot be cast to class sun.nio.fs.UnixPath (us.hall.trz.osx.MacPath is in unnamed module of loader 'app'; sun.nio.fs.UnixPath is in module java.base of loader 'bootstrap') at java.base/sun.nio.fs.UnixPath.compareTo(Unknown Source) at java.base/javax.crypto.JceSecurity.setupJurisdictionPolicies(Unknown Source) at java.base/javax.crypto.JceSecurity$1.run(Unknown Source) at java.base/javax.crypto.JceSecurity$1.run(Unknown Source) at java.base/java.security.AccessController.doPrivileged(Unknown Source) ... 38 more My own MacPath class has? @Override public int compareTo(Path other) { if (other instanceof MacPath) return proxy.compareTo(((MacPath)other).proxy); return proxy.compareTo(other); } Trying to passthrough defer everything to the platform proxy instance. Maybe for Path that is Unix if the Mac doesn?t have it?s own Path class. I?m not sure how the Unix provider gets involved although the Mac might extend that. This came out of startup. I have not made any direct attempt to use any FileServer functionality at this point. From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 26 06:43:31 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 26 Mar 2021 06:43:31 GMT Subject: RFR: JDK-8262957 (fs) Fail fast in UnixFileStore.isExtendedAttributesEnabled In-Reply-To: References: <3oC7RYLaLrQGrEdqrGV9oSIs_hQbY8GVuVg9SL9_v1M=.d809d1cf-9474-4177-a008-773c69f60354@github.com> <5zypJQRKllJ-CTbg2rNjwyOwWx1bEnc24dbszBCDsNc=.716bd821-0e38-4252-85d7-eeb8907446af@github.com> Message-ID: On Wed, 24 Mar 2021 08:46:41 GMT, Alan Bateman wrote: >> I just wanted to create another issue, but then I noticed that `close(-1)` is allowed as per contract: https://github.com/openjdk/jdk/blob/45e1bab87ccebd498d4f927a008dd89a47dd177b/src/java.base/unix/classes/sun/nio/fs/UnixNativeDispatcher.java#L90-L97 >> >> We can still change this, of course, but I wouldn't consider this a necessary change for this PR and would therefore suggest to deal with this another time. > > Okay, I had forgotten that that UnixNativeDispatcher.close(-1) is a no-op. I guess we're good to merge, then? ------------- PR: https://git.openjdk.java.net/jdk/pull/2816 From alanb at openjdk.java.net Fri Mar 26 07:06:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 26 Mar 2021 07:06:27 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v3] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 22:16:46 GMT, Brian Burkhalter wrote: >> This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > Remove whitespace test/jdk/java/nio/file/Files/NullDevice.java line 44: > 42: } > 43: } > 44: } The updated changes to the Windows file system provider looks good. Have you checked that WindowsNativeDispatcher.GetFileSizeEx returns the correct size for a non-zero length file? (asking about that because it won't be exercised by the any of the tests and we might want to use it in order places). The test name is "NullDevice" but it actually tests "nul" :-) so maybe it should be renamed. Files.newOutputStream is just one way to open the NUL device for writing. Would be good to also test opening it for wring without the TRUNCATE_EXISTING operation. I think we should do reading while we are there. You can use Path.of("nul") to avoid first creating a java.io.File and using toPath. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From alanb at openjdk.java.net Fri Mar 26 07:15:33 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 26 Mar 2021 07:15:33 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write [v2] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 11:53:01 GMT, Sebastian Stenzel wrote: >> src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 174: >> >>> 172: if (dst instanceof sun.nio.ch.DirectBuffer buf) { >>> 173: long address = buf.address() + pos; >>> 174: int n = read(name, address, rem); >> >> We need to add reachabilityFence here, don't mind if we do it now while changing this code or later. >> That is, it should be try { n = read(name, address, rem); } finally { Reference.reachabilityFence(buf); } > > Never heard of this before, just read the docs the first time. Do I get this right, that this helps to protect against instant finalization of the buffer in e.g. `attrView.read("foo", ByteBuffer.allocateDirect(42))`? > > What about the `write` case? Yes, everywhere where the direct memory is accessed (so read and write here). I don't mind if we do it as a separate issue or here, I only suggested it here because it's changed the new code in this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/3171 From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 26 08:02:40 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 26 Mar 2021 08:02:40 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write [v3] In-Reply-To: References: Message-ID: > Added new private methods for `read(String name, long address, int rem)` and `write(String name, long address, int rem)` that take an address as an argument and thereby no longer need to deal with any NativeBuffers. > > This allows a certain simplification of `read(String name, ByteBuffer dst)` and `write(String name, ByteBuffer src)` and use of `try (NativeBuffer nb = NativeBuffers.getNativeBuffer(rem)) {...}` which fixes the issue. Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: Added reachabilityFence when dealing with DirectBuffer ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3171/files - new: https://git.openjdk.java.net/jdk/pull/3171/files/d3cb759b..2f1f2132 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3171&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3171&range=01-02 Stats: 16 lines in 1 file changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3171/head:pull/3171 PR: https://git.openjdk.java.net/jdk/pull/3171 From alanb at openjdk.java.net Fri Mar 26 09:05:25 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 26 Mar 2021 09:05:25 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write [v3] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 11:37:34 GMT, Alan Bateman wrote: >> Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: >> >> Added reachabilityFence when dealing with DirectBuffer > > This looks good. > Would you mind adding "@Override" to the public write method so it is consistent with the other public methods. Thanks for the update. Can you add the import of java.lang.ref.Reference so that it compiles? Happy to sponsor once the tests are passing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3171 From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 26 09:16:43 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 26 Mar 2021 09:16:43 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write [v4] In-Reply-To: References: Message-ID: > Added new private methods for `read(String name, long address, int rem)` and `write(String name, long address, int rem)` that take an address as an argument and thereby no longer need to deal with any NativeBuffers. > > This allows a certain simplification of `read(String name, ByteBuffer dst)` and `write(String name, ByteBuffer src)` and use of `try (NativeBuffer nb = NativeBuffers.getNativeBuffer(rem)) {...}` which fixes the issue. Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: added import ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3171/files - new: https://git.openjdk.java.net/jdk/pull/3171/files/2f1f2132..e37be841 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3171&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3171&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3171/head:pull/3171 PR: https://git.openjdk.java.net/jdk/pull/3171 From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 26 09:16:43 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 26 Mar 2021 09:16:43 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write [v4] In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 09:02:58 GMT, Alan Bateman wrote: >> This looks good. >> Would you mind adding "@Override" to the public write method so it is consistent with the other public methods. > > Thanks for the update. Can you add the import of java.lang.ref.Reference so that it compiles? Happy to sponsor once the tests are passing. Crap, how could I miss that. ?? It's now building again: TEST TOTAL PASS FAIL ERROR jtreg:test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView 1 1 0 0 ------------- PR: https://git.openjdk.java.net/jdk/pull/3171 From alanb at openjdk.java.net Fri Mar 26 14:31:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 26 Mar 2021 14:31:27 GMT Subject: RFR: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write [v4] In-Reply-To: References: Message-ID: <8Za3oI0YA-_pxUS4yUB-rA67sGBD3BEt1AsTodgYNeY=.5a6d4857-44a2-4f16-a3d5-8ebb0f82e111@github.com> On Fri, 26 Mar 2021 09:16:43 GMT, Sebastian Stenzel wrote: >> Added new private methods for `read(String name, long address, int rem)` and `write(String name, long address, int rem)` that take an address as an argument and thereby no longer need to deal with any NativeBuffers. >> >> This allows a certain simplification of `read(String name, ByteBuffer dst)` and `write(String name, ByteBuffer src)` and use of `try (NativeBuffer nb = NativeBuffers.getNativeBuffer(rem)) {...}` which fixes the issue. > > Sebastian Stenzel has updated the pull request incrementally with one additional commit since the last revision: > > added import Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3171 From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 26 15:01:27 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 26 Mar 2021 15:01:27 GMT Subject: Integrated: JDK-8264111 (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write In-Reply-To: References: Message-ID: On Wed, 24 Mar 2021 10:37:56 GMT, Sebastian Stenzel wrote: > Added new private methods for `read(String name, long address, int rem)` and `write(String name, long address, int rem)` that take an address as an argument and thereby no longer need to deal with any NativeBuffers. > > This allows a certain simplification of `read(String name, ByteBuffer dst)` and `write(String name, ByteBuffer src)` and use of `try (NativeBuffer nb = NativeBuffers.getNativeBuffer(rem)) {...}` which fixes the issue. This pull request has now been integrated. Changeset: 4e74de4b Author: Sebastian Stenzel Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/4e74de4b Stats: 89 lines in 1 file changed: 27 ins; 20 del; 42 mod 8264111: (fs) Leaking NativeBuffers in case of errors during UnixUserDefinedFileAttributeView.read/write Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3171 From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 26 15:05:36 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 26 Mar 2021 15:05:36 GMT Subject: RFR: JDK-8262958 (fs) UnixUserDefinedFileAttributeView cleanup Message-ID: `flistxattr` gets called in two places: 1. Obviously during `list()` 2. When copying xattr from one file to another using `copyExtendedAttributes()` Commit 7104008 adds a new private method `List list(int fd, int bufSize) throws UnixException` that takes care of the "retry if buffer too small" logic that previously happened inside of two almost identical for-loops. In order to properly reuse the same code in both places, I move the stripping of the `USER_NAMESPACE` attr prefix from `asList` to `list()`, which I'd consider an undocumented side effect of the former anyway. This also significantly reduced complexity in both affected methods, but in turn `copyExtendedAttributes` will now deal with Strings instead of bytes for the attr names. While I am convinced that the benefits outweighs this point, I don't want to leave this unmentioned, as this change might slightly affect performance of `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)`. ------------- Commit messages: - Merge branch 'master' into JDK-8262958 - renamed variable - Stream.toList() is already unmodifiable - deduplicated flistxattr-related code Changes: https://git.openjdk.java.net/jdk/pull/2916/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2916&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262958 Stats: 95 lines in 1 file changed: 19 ins; 57 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/2916.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2916/head:pull/2916 PR: https://git.openjdk.java.net/jdk/pull/2916 From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 26 15:23:31 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 26 Mar 2021 15:23:31 GMT Subject: RFR: JDK-8264110 (fs) possible UnsupportedOperationException in UnixUserDefinedFileAttributeView.read(...) Message-ID: During `write()`, we check whether the `src` buffer exposes a raw byte array: https://github.com/openjdk/jdk/blob/4e74de4b2eec611b49ee8defae1ab06351280008/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L247-L258 The same is now also done during `read()`. This should allow using arbitrary ByteBuffer implementations as `dst` and restores a certain symmetry between read and write. ------------- Commit messages: - use tmp array, if buffer doesn't have an array Changes: https://git.openjdk.java.net/jdk/pull/3217/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3217&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264110 Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3217.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3217/head:pull/3217 PR: https://git.openjdk.java.net/jdk/pull/3217 From bpb at openjdk.java.net Fri Mar 26 16:07:25 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 26 Mar 2021 16:07:25 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v3] In-Reply-To: <_6flSILtpbkRtk8l8uZbiEKCnrzHDaQ-EpYni8QZv7E=.4b2de221-5aa5-44b0-b5f0-3d1ca67bb91b@github.com> References: <_6flSILtpbkRtk8l8uZbiEKCnrzHDaQ-EpYni8QZv7E=.4b2de221-5aa5-44b0-b5f0-3d1ca67bb91b@github.com> Message-ID: On Fri, 26 Mar 2021 01:16:46 GMT, Jaikiran Pai wrote: > The test case (changes) looks fine to me. Thank you Brian. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Fri Mar 26 16:10:27 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 26 Mar 2021 16:10:27 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v3] In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 07:03:51 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove whitespace > > test/jdk/java/nio/file/Files/NullDevice.java line 44: > >> 42: } >> 43: } >> 44: } > > The updated changes to the Windows file system provider looks good. Have you checked that WindowsNativeDispatcher.GetFileSizeEx returns the correct size for a non-zero length file? (asking about that because it won't be exercised by the any of the tests and we might want to use it in order places). > > The test name is "NullDevice" but it actually tests "nul" :-) so maybe it should be renamed. Files.newOutputStream is just one way to open the NUL device for writing. Would be good to also test opening it for wring without the TRUNCATE_EXISTING operation. I think we should do reading while we are there. > You can use Path.of("nul") to avoid first creating a java.io.File and using toPath. I don't have the length check in public code. I'll see how it is possible. I'll translate "null" into French and look at the reading and writing cases. I should have thought to use `Path.of()` especially given that I wrote it (JDK-8194746). ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From alanb at openjdk.java.net Fri Mar 26 16:59:25 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 26 Mar 2021 16:59:25 GMT Subject: RFR: JDK-8264110 (fs) possible UnsupportedOperationException in UnixUserDefinedFileAttributeView.read(...) In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 15:11:54 GMT, Sebastian Stenzel wrote: > During `write()`, we check whether the `src` buffer exposes a raw byte array: > > https://github.com/openjdk/jdk/blob/4e74de4b2eec611b49ee8defae1ab06351280008/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L247-L258 > > The same is now also done during `read()`. This should allow using arbitrary ByteBuffer implementations as `dst` and restores a certain symmetry between read and write. src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 197: > 195: unsafe.copyMemory(null, address, tmp, 0, n); > 196: dst.put(tmp); > 197: } The changes look okay but I'm wondering what cases you have in mind so that we can add tests. We lack tests that use of these APIs with buffers that are created with JNI NewDirectByteBuffer. ------------- PR: https://git.openjdk.java.net/jdk/pull/3217 From bpb at openjdk.java.net Fri Mar 26 18:59:48 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 26 Mar 2021 18:59:48 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v4] In-Reply-To: References: Message-ID: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: Rename test to NulDevice and improve ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3183/files - new: https://git.openjdk.java.net/jdk/pull/3183/files/8389cda0..079b7854 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=02-03 Stats: 116 lines in 2 files changed: 72 ins; 44 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3183/head:pull/3183 PR: https://git.openjdk.java.net/jdk/pull/3183 From github.com+1204330+overheadhunter at openjdk.java.net Fri Mar 26 19:06:27 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Fri, 26 Mar 2021 19:06:27 GMT Subject: RFR: JDK-8264110 (fs) possible UnsupportedOperationException in UnixUserDefinedFileAttributeView.read(...) In-Reply-To: References: Message-ID: <7TYxjy_8fVYXg2f1bHVtOrM3551Mx3GPXl4J_KuQ7qM=.e4a64b89-160f-4fa3-a757-1db295e46a53@github.com> On Fri, 26 Mar 2021 16:56:15 GMT, Alan Bateman wrote: >> During `write()`, we check whether the `src` buffer exposes a raw byte array: >> >> https://github.com/openjdk/jdk/blob/4e74de4b2eec611b49ee8defae1ab06351280008/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L247-L258 >> >> The same is now also done during `read()`. This should allow using arbitrary ByteBuffer implementations as `dst` and restores a certain symmetry between read and write. > > src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 197: > >> 195: unsafe.copyMemory(null, address, tmp, 0, n); >> 196: dst.put(tmp); >> 197: } > > The changes look okay but I'm wondering what cases you have in mind so that we can add tests. We lack tests that use of these APIs with buffers that are created with JNI NewDirectByteBuffer. Tbh, I don't know any specific ByteBuffer implementation (other than DirectByteBuffer) that doesn't have an array, but in theory it is explicitly allowed. And since this `read(String name, ByteBuffer dst)` is public API, it should be prepared to deal with any allowed params. But after all I didn't encounter any exception, I just copied the implementation from `write()` as I deemed it reasonable. Alternatively, if ByteBuffers were sealed classes and only allowed HeapByteBuffers (known to have an array) or DirectByteBuffers (allowing direct access to the address, thus irrelevant in this part of the code) we could skip the distinction entirely. But I guess that isn't something we can decide in the scope of this PR. Regarding test cases: Other than creating a ByteBuffer mock that returns false upon `hasArray()`, I don't know how to verify this branch. That said, so far I failed to understand what framework or pattern to use to write JDK tests. The UserDefinedAttributeView test seems to be a mere `main(String[] args)` class that must not complete exceptionally. ------------- PR: https://git.openjdk.java.net/jdk/pull/3217 From bpb at openjdk.java.net Fri Mar 26 22:06:43 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Fri, 26 Mar 2021 22:06:43 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v5] In-Reply-To: References: Message-ID: <5ji0UY3BcAwBuPxDjPmDJUFNTYmGfBi3HF3YizTUEmg=.199f436a-c373-4e79-90e6-c6c8b37e75b6@github.com> > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8263898: Fix accidentally reverted copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3183/files - new: https://git.openjdk.java.net/jdk/pull/3183/files/079b7854..f799631d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=03-04 Stats: 4 lines in 3 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3183/head:pull/3183 PR: https://git.openjdk.java.net/jdk/pull/3183 From alanb at openjdk.java.net Sat Mar 27 15:43:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 27 Mar 2021 15:43:27 GMT Subject: RFR: JDK-8264110 (fs) possible UnsupportedOperationException in UnixUserDefinedFileAttributeView.read(...) In-Reply-To: <7TYxjy_8fVYXg2f1bHVtOrM3551Mx3GPXl4J_KuQ7qM=.e4a64b89-160f-4fa3-a757-1db295e46a53@github.com> References: <7TYxjy_8fVYXg2f1bHVtOrM3551Mx3GPXl4J_KuQ7qM=.e4a64b89-160f-4fa3-a757-1db295e46a53@github.com> Message-ID: On Fri, 26 Mar 2021 19:03:57 GMT, Sebastian Stenzel wrote: >> src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java line 197: >> >>> 195: unsafe.copyMemory(null, address, tmp, 0, n); >>> 196: dst.put(tmp); >>> 197: } >> >> The changes look okay but I'm wondering what cases you have in mind so that we can add tests. We lack tests that use of these APIs with buffers that are created with JNI NewDirectByteBuffer. > > Tbh, I don't know any specific ByteBuffer implementation (other than DirectByteBuffer) that doesn't have an array, but in theory it is explicitly allowed. And since this `read(String name, ByteBuffer dst)` is public API, it should be prepared to deal with any allowed params. > > But after all I didn't encounter any exception, I just copied the implementation from `write()` as I deemed it reasonable. > > Alternatively, if ByteBuffers were sealed classes and only allowed HeapByteBuffers (known to have an array) or DirectByteBuffers (allowing direct access to the address, thus irrelevant in this part of the code) we could skip the distinction entirely. But I guess that isn't something we can decide in the scope of this PR. > > Regarding test cases: Other than creating a ByteBuffer mock that returns false upon `hasArray()`, I don't know how to verify this branch. That said, so far I failed to understand what framework or pattern to use to write JDK tests. The UserDefinedAttributeView test seems to be a mere `main(String[] args)` class that must not complete exceptionally. Buffers are closed abstraction and cannot be implemented outside of the java.nio package. When sealed classes are promoted from preview to be a permanent feature then maybe we should look at make them sealed. For now, I think the only scenario where the reported issue can arise is when someone injects their own class into java.nio, maybe a mock as you suggest. I'm not opposed to handling such cases but I suspect it would require work in several other areas of the JDK that currently have to distinguish between heap and direct buffers. As regards tests, then yes, the basic unit test for UserDefinedAttributeView is an old style jtreg test. It pre-dates support for TestNG and other frameworks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3217 From alanb at openjdk.java.net Sat Mar 27 15:57:26 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 27 Mar 2021 15:57:26 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v5] In-Reply-To: <5ji0UY3BcAwBuPxDjPmDJUFNTYmGfBi3HF3YizTUEmg=.199f436a-c373-4e79-90e6-c6c8b37e75b6@github.com> References: <5ji0UY3BcAwBuPxDjPmDJUFNTYmGfBi3HF3YizTUEmg=.199f436a-c373-4e79-90e6-c6c8b37e75b6@github.com> Message-ID: On Fri, 26 Mar 2021 22:06:43 GMT, Brian Burkhalter wrote: >> This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8263898: Fix accidentally reverted copyright year The change looks okay. The test looks okay although there other cases that probably should be added at some point, in particular, FileChannel.open for reading, and AsynchronousFileChannel read & write. test/jdk/java/nio/file/Files/NulDevice.java line 41: > 39: public class NulDevice { > 40: public static void main(final String[] args) throws IOException { > 41: System.getProperties().list(System.out); Is the printing of the system properties a left-over? ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3183 From github.com+1204330+overheadhunter at openjdk.java.net Sat Mar 27 21:51:25 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Sat, 27 Mar 2021 21:51:25 GMT Subject: RFR: JDK-8264110 (fs) possible UnsupportedOperationException in UnixUserDefinedFileAttributeView.read(...) In-Reply-To: References: <7TYxjy_8fVYXg2f1bHVtOrM3551Mx3GPXl4J_KuQ7qM=.e4a64b89-160f-4fa3-a757-1db295e46a53@github.com> Message-ID: <4Ofery2445H85ofL6G-bmmten1RZ692eDMytR_2sQis=.61ae9134-7d9f-4eca-85e1-dfaf6d3f22b8@github.com> On Sat, 27 Mar 2021 15:40:47 GMT, Alan Bateman wrote: >> Tbh, I don't know any specific ByteBuffer implementation (other than DirectByteBuffer) that doesn't have an array, but in theory it is explicitly allowed. And since this `read(String name, ByteBuffer dst)` is public API, it should be prepared to deal with any allowed params. >> >> But after all I didn't encounter any exception, I just copied the implementation from `write()` as I deemed it reasonable. >> >> Alternatively, if ByteBuffers were sealed classes and only allowed HeapByteBuffers (known to have an array) or DirectByteBuffers (allowing direct access to the address, thus irrelevant in this part of the code) we could skip the distinction entirely. But I guess that isn't something we can decide in the scope of this PR. >> >> Regarding test cases: Other than creating a ByteBuffer mock that returns false upon `hasArray()`, I don't know how to verify this branch. That said, so far I failed to understand what framework or pattern to use to write JDK tests. The UserDefinedAttributeView test seems to be a mere `main(String[] args)` class that must not complete exceptionally. > > Buffers are closed abstraction and cannot be implemented outside of the java.nio package. When sealed classes are promoted from preview to be a permanent feature then maybe we should look at make them sealed. For now, I think the only scenario where the reported issue can arise is when someone injects their own class into java.nio, maybe a mock as you suggest. I'm not opposed to handling such cases but I suspect it would require work in several other areas of the JDK that currently have to distinguish between heap and direct buffers. > > As regards tests, then yes, the basic unit test for UserDefinedAttributeView is an old style jtreg test. It pre-dates support for TestNG and other frameworks. If we can be sure that the buffers are either direct or have an array, I suggest we close this PR unresolved, change the write method and add a corresponding assertion to both methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/3217 From mik3hall at gmail.com Sun Mar 28 04:02:16 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 27 Mar 2021 23:02:16 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <82C800B3-F6DD-4E62-953D-94BF5E2A74B7@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> <87BB5333-F466-4450-B8AC-208B0832DBCE@gmail.com> <82C800B3-F6DD-4E62-953D-94BF5E2A74B7@gmail.com> Message-ID: <37485C29-67A0-4A96-87CA-1C61BA5F12B0@gmail.com> > On Mar 25, 2021, at 9:25 PM, Michael Hall wrote: > > Caused by: java.lang.ClassCastException: class us.hall.trz.osx.MacPath cannot be cast to class sun.nio.fs.UnixPath (us.hall.trz.osx.MacPath is in unnamed module of loader 'app'; sun.nio.fs.UnixPath is in module java.base of loader 'bootstrap') > at java.base/sun.nio.fs.UnixPath.compareTo(Unknown Source) Maybe understand this a little bit. My application REST API?s using Apache HttpClient are not working. ava.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$CustomizedTLSContext at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Unknown Source) at java.base/java.security.Provider$Service.getImplClass(Unknown Source) at java.base/java.security.Provider$Service.newInstance(Unknown Source) Debugging messages show? 2021-03-27 22:34:16.849 HalfPipe[5244:239243] MacPath: unlimited 2021-03-27 22:34:16.849 HalfPipe[5244:239243] MacPath: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/conf/security/policy 2021-03-27 22:34:16.849 HalfPipe[5244:239243] MacPath: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/conf/security/policy 2021-03-27 22:34:16.850 HalfPipe[5244:239243] MacPath: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/conf/security/policy/unlimited 2021-03-27 22:34:16.850 HalfPipe[5244:239243] MacPath: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/conf/security/policy/unlimited 2021-03-27 22:34:16.854 HalfPipe[5244:239243] java.lang.Exception: UnixPath ?that I am trying to access security files in the runtime conf directory just before the error. This is very similar to this StackOverflow I found? Apache HttpClient failing with Java 11 on macOS https://stackoverflow.com/questions/61185934/apache-httpclient-failing-with-java-11-on-macos Getting a nearly identical error when these files couldn?t be found. They are there for me but I think with my FileSystemProvider I instead get the ClassCastException from the Unix provider. I don?t get enough of the stack trace to know why I end up with a Unix provider. Maybe I could come up with a simple test case where I?d get the full error. UnixPath for the source I have does? @Override public int compareTo(Path other) { int len1 = path.length; int len2 = ((UnixPath) other).path.length; int n = Math.min(len1, len2); byte v1[] = path; byte v2[] = ((UnixPath) other).path; Code that casts like this if it is reached will never work with an overridden DefaultFileSystemProvider instance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Sun Mar 28 14:44:41 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 28 Mar 2021 09:44:41 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: <37485C29-67A0-4A96-87CA-1C61BA5F12B0@gmail.com> References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> <87BB5333-F466-4450-B8AC-208B0832DBCE@gmail.com> <82C800B3-F6DD-4E62-953D-94BF5E2A74B7@gmail.com> <37485C29-67A0-4A96-87CA-1C61BA5F12B0@gmail.com> Message-ID: > On Mar 27, 2021, at 11:02 PM, Michael Hall wrote: > > > >> On Mar 25, 2021, at 9:25 PM, Michael Hall > wrote: >> >> Caused by: java.lang.ClassCastException: class us.hall.trz.osx.MacPath cannot be cast to class sun.nio.fs.UnixPath (us.hall.trz.osx.MacPath is in unnamed module of loader 'app'; sun.nio.fs.UnixPath is in module java.base of loader 'bootstrap') >> at java.base/sun.nio.fs.UnixPath.compareTo(Unknown Source) > > Maybe understand this a little bit. > > My application REST API?s using Apache HttpClient are not working. > > ava.lang.NoClassDefFoundError: Could not initialize class sun.security.ssl.SSLContextImpl$CustomizedTLSContext > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Unknown Source) > at java.base/java.security.Provider$Service.getImplClass(Unknown Source) > at java.base/java.security.Provider$Service.newInstance(Unknown Source) > > Debugging messages show? > 2021-03-27 22:34:16.849 HalfPipe[5244:239243] MacPath: unlimited > 2021-03-27 22:34:16.849 HalfPipe[5244:239243] MacPath: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/conf/security/policy > 2021-03-27 22:34:16.849 HalfPipe[5244:239243] MacPath: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/conf/security/policy > 2021-03-27 22:34:16.850 HalfPipe[5244:239243] MacPath: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/conf/security/policy/unlimited > 2021-03-27 22:34:16.850 HalfPipe[5244:239243] MacPath: /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home/conf/security/policy/unlimited > 2021-03-27 22:34:16.854 HalfPipe[5244:239243] java.lang.Exception: UnixPath > > ?that I am trying to access security files in the runtime conf directory just before the error. > This is very similar to this StackOverflow I found? > > Apache HttpClient failing with Java 11 on macOS > https://stackoverflow.com/questions/61185934/apache-httpclient-failing-with-java-11-on-macos > > Getting a nearly identical error when these files couldn?t be found. > They are there for me but I think with my FileSystemProvider I instead get the ClassCastException from the Unix provider. I don?t get enough of the stack trace to know why I end up with a Unix provider. Maybe I could come up with a simple test case where I?d get the full error. > > UnixPath for the source I have does? > @Override > public int compareTo(Path other) { > int len1 = path.length; > int len2 = ((UnixPath) other).path.length; > > int n = Math.min(len1, len2); > byte v1[] = path; > byte v2[] = ((UnixPath) other).path; > > Code that casts like this if it is reached will never work with an overridden DefaultFileSystemProvider instance. > > > Simple reproducing test case? import org.apache.hc.client5.http.impl.classic.HttpClientBuilder; import org.apache.hc.client5.http.impl.classic.CloseableHttpClient; public class TestREST { public static void main(String[] args) { try (CloseableHttpClient client = HttpClientBuilder.create().build();) { } catch (ClassCastException cce) { System.out.println("as cce"); cce.printStackTrace(); } catch (java.io.IOException ioex) { System.out.println("as ioex"); } } } Compile javac -cp outputdir/HalfPipe.app/Contents/app/httpclient5-5.0.3.jar:outputdir/HalfPipe.app/Contents/app/httpcore5-5.0.2.jar TestREST.java Run java -cp .:outputdir/HalfPipe.app/Contents/app/httpclient5-5.0.3.jar:outputdir/HalfPipe.app/Contents/app/httpcore5-5.0.2.jar:outputdir/HalfPipe.app/Contents/app/slf4j-api-1.7.7.jar -Djava.nio.file.spi.DefaultFileSystemProvider=us.hall.trz.osx.MacFileSystemProvider TestREST Which picks up my exploded provider in the current directory. I haven?t figured out how to get the full ClassCastException stack trace or thought of any other way to determine why a Unix provider Path instance is involved. I could bug report if it seems to make sense? It does break functionality when I turn on my default provider for my application. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Mar 28 15:17:04 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Mar 2021 16:17:04 +0100 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> <87BB5333-F466-4450-B8AC-208B0832DBCE@gmail.com> <82C800B3-F6DD-4E62-953D-94BF5E2A74B7@gmail.com> <37485C29-67A0-4A96-87CA-1C61BA5F12B0@gmail.com> Message-ID: On 28/03/2021 15:44, Michael Hall wrote: > > Simple reproducing test case? > > import org.apache.hc.client5.http.impl.classic.HttpClientBuilder; > import org.apache.hc.client5.http.impl.classic.CloseableHttpClient; > > public class TestREST { > > > public static void main(String[] args) { > try (CloseableHttpClient client = HttpClientBuilder.create().build();) { > } > catch (ClassCastException cce) { > System.out.println("as cce"); > cce.printStackTrace(); > } > catch (java.io.IOException ioex) { > System.out.println("as ioex"); > } > } > } > My guess is that this CCE is due to somewhere in the custom file system provider that isn't wrapping or unwrapping consistently. I've run several tests based on the TestProvider that I linked to and I couldn't duplicate the issue. The SO post that you linked to seems to be something else. The cryptographic jurisdiction policy defaults to "unlimited" since JDK 9 so I wouldn't expect any issues there, unless conf/security/java.security has been changed to set crypto.policy to "limited" and I doubt that is the case. -Alan. || -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.java.net Sun Mar 28 15:24:31 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 28 Mar 2021 15:24:31 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v5] In-Reply-To: <5ji0UY3BcAwBuPxDjPmDJUFNTYmGfBi3HF3YizTUEmg=.199f436a-c373-4e79-90e6-c6c8b37e75b6@github.com> References: <5ji0UY3BcAwBuPxDjPmDJUFNTYmGfBi3HF3YizTUEmg=.199f436a-c373-4e79-90e6-c6c8b37e75b6@github.com> Message-ID: On Fri, 26 Mar 2021 22:06:43 GMT, Brian Burkhalter wrote: >> This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8263898: Fix accidentally reverted copyright year test/jdk/java/nio/file/Files/NulDevice.java line 47: > 45: os.write(0x02); > 46: System.out.printf("Wrote a byte to %s%n", path); > 47: try (InputStream is = Files.newInputStream(path);) { One other test that you could add here is to test that available() returns 0. I've no doubt there are many file operations that will behavior in surprising ways when using the special "NUL" device if the common operations work in unsurprising ways then it would help. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From alanb at openjdk.java.net Sun Mar 28 15:26:34 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 28 Mar 2021 15:26:34 GMT Subject: RFR: JDK-8264110 (fs) possible UnsupportedOperationException in UnixUserDefinedFileAttributeView.read(...) In-Reply-To: <4Ofery2445H85ofL6G-bmmten1RZ692eDMytR_2sQis=.61ae9134-7d9f-4eca-85e1-dfaf6d3f22b8@github.com> References: <7TYxjy_8fVYXg2f1bHVtOrM3551Mx3GPXl4J_KuQ7qM=.e4a64b89-160f-4fa3-a757-1db295e46a53@github.com> <4Ofery2445H85ofL6G-bmmten1RZ692eDMytR_2sQis=.61ae9134-7d9f-4eca-85e1-dfaf6d3f22b8@github.com> Message-ID: <40QIvYyyAg2v4PfcVTkQis2UFGR22KviyhmTyC_Rf7M=.f1a6851b-8aa9-46d4-81f2-c74da4df457e@github.com> On Sat, 27 Mar 2021 21:48:49 GMT, Sebastian Stenzel wrote: >> Buffers are closed abstraction and cannot be implemented outside of the java.nio package. When sealed classes are promoted from preview to be a permanent feature then maybe we should look at make them sealed. For now, I think the only scenario where the reported issue can arise is when someone injects their own class into java.nio, maybe a mock as you suggest. I'm not opposed to handling such cases but I suspect it would require work in several other areas of the JDK that currently have to distinguish between heap and direct buffers. >> >> As regards tests, then yes, the basic unit test for UserDefinedAttributeView is an old style jtreg test. It pre-dates support for TestNG and other frameworks. > > If we can be sure that the buffers are either direct or have an array, I suggest we close this PR unresolved, change the write method and add a corresponding assertion to both methods. Closing this PR/issue and drop the code from write sounds good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3217 From mik3hall at gmail.com Sun Mar 28 16:40:12 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 28 Mar 2021 11:40:12 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> <87BB5333-F466-4450-B8AC-208B0832DBCE@gmail.com> <82C800B3-F6DD-4E62-953D-94BF5E2A74B7@gmail.com> <37485C29-67A0-4A96-87CA-1C61BA5F12B0@gmail.com> Message-ID: > On Mar 28, 2021, at 10:17 AM, Alan Bateman wrote: > > On 28/03/2021 15:44, Michael Hall wrote: >> >> Simple reproducing test case? >> >> import org.apache.hc.client5.http.impl.classic.HttpClientBuilder; >> import org.apache.hc.client5.http.impl.classic.CloseableHttpClient; >> >> public class TestREST { >> >> >> public static void main(String[] args) {th >> try (CloseableHttpClient client = HttpClientBuilder.create().build();) { >> } >> catch (ClassCastException cce) { >> System.out.println("as cce"); >> cce.printStackTrace(); >> } >> catch (java.io.IOException ioex) { >> System.out.println("as ioex"); >> } >> } >> } >> > My guess is that this CCE is due to somewhere in the custom file system provider that isn't wrapping or unwrapping consistently. I've run several tests based on the TestProvider that I linked to and I couldn't duplicate the issue. > > The SO post that you linked to seems to be something else. The cryptographic jurisdiction policy defaults to "unlimited" since JDK 9 so I wouldn't expect any issues there, unless conf/security/java.security has been changed to set crypto.policy to "limited" and I doubt that is the case. > > -Alan. Could be difficult to track down if I?m letting a Unix through. I?m not quite sure how since that isn?t even the platform provider. But I?ll try to figure it out. It looks like UnixPath is the only builtin Path implementation present. No MacOSX or Bsd. So it would have to be somewhere I defer to platform that instantiates or returns a Path instance I would guess. The SO I indicated just ended up with an identical result when it couldn?t access files in the conf directory. I think mine is the same in that regard. I think somehow in HttpClient trying to access something in that directory the CCE is thrown. Thanks for the reply and confirmation you didn?t reproduce. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik3hall at gmail.com Sun Mar 28 23:50:50 2021 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 28 Mar 2021 18:50:50 -0500 Subject: Replacing default FileSystemProvider In-Reply-To: References: <2B7392BC-6296-444E-AD06-D93A45E006CA@gmail.com> <6520DDA1-9E48-40C9-90E1-D5F0565CA193@oracle.com> <05E38BA3-6712-4C24-B232-22169AD6709C@gmail.com> <7dca2c6b-0ea9-a0f0-ef6e-4adcdc835fb7@oracle.com> <8A8B3810-257E-4797-8B65-7D2C14F04B6C@gmail.com> <0FE0636B-1171-43D9-B06F-9B6966203E9E@gmail.com> <060e448e-1a79-2710-e95c-13851da9948f@oracle.com> <87d6e867-d909-f765-7d6c-8be2ddf767c1@oracle.com> <87BB5333-F466-4450-B8AC-208B0832DBCE@gmail.com> <82C800B3-F6DD-4E62-953D-94BF5E2A74B7@gmail.com> <37485C29-67A0-4A96-87CA-1C61BA5F12B0@gmail.com> Message-ID: > On Mar 28, 2021, at 11:40 AM, Michael Hall wrote: > > > >> On Mar 28, 2021, at 10:17 AM, Alan Bateman > wrote: >> >>> >> My guess is that this CCE is due to somewhere in the custom file system provider that isn't wrapping or unwrapping consistently. I've run several tests based on the TestProvider that I linked to and I couldn't duplicate the issue. >> Exactly correct about inconsisten wrapping . About half the methods for my Path class that returned Path?s directly returned the platform ones and about half returned ones where I wrapped the returned as my class. I changed to wrap all returned Path?s and the test and my application work. So I have a version of the application that fully replaces com.apple.eio.FileManager including functionionality from my DefaultFileSystemProvider. The application requires some changes after jpackage puts it together to include the exploded classes as per earlier. I will try to figure that out and maybe add a little code that further utilizes the DefaultFileSystemProvider. But working more or less as I intended the 5 or 6 years ago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From github.com+1204330+overheadhunter at openjdk.java.net Mon Mar 29 07:55:33 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Mon, 29 Mar 2021 07:55:33 GMT Subject: RFR: JDK-8264110 (fs) possible UnsupportedOperationException in UnixUserDefinedFileAttributeView.read(...) In-Reply-To: <40QIvYyyAg2v4PfcVTkQis2UFGR22KviyhmTyC_Rf7M=.f1a6851b-8aa9-46d4-81f2-c74da4df457e@github.com> References: <7TYxjy_8fVYXg2f1bHVtOrM3551Mx3GPXl4J_KuQ7qM=.e4a64b89-160f-4fa3-a757-1db295e46a53@github.com> <4Ofery2445H85ofL6G-bmmten1RZ692eDMytR_2sQis=.61ae9134-7d9f-4eca-85e1-dfaf6d3f22b8@github.com> <40QIvYyyAg2v4PfcVTkQis2UFGR22KviyhmTyC_Rf7M=.f1a6851b-8aa9-46d4-81f2-c74da4df457e@github.com> Message-ID: On Sun, 28 Mar 2021 15:23:53 GMT, Alan Bateman wrote: >> If we can be sure that the buffers are either direct or have an array, I suggest we close this PR unresolved, change the write method and add a corresponding assertion to both methods. > > Closing this PR/issue and drop the code from write sounds good. Created a new issue to remove the code from `write(...)`: [JDK-8264341](https://bugs.openjdk.java.net/browse/JDK-8264341) ------------- PR: https://git.openjdk.java.net/jdk/pull/3217 From github.com+1204330+overheadhunter at openjdk.java.net Mon Mar 29 07:55:33 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Mon, 29 Mar 2021 07:55:33 GMT Subject: Withdrawn: JDK-8264110 (fs) possible UnsupportedOperationException in UnixUserDefinedFileAttributeView.read(...) In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 15:11:54 GMT, Sebastian Stenzel wrote: > During `write()`, we check whether the `src` buffer exposes a raw byte array: > > https://github.com/openjdk/jdk/blob/4e74de4b2eec611b49ee8defae1ab06351280008/src/java.base/unix/classes/sun/nio/fs/UnixUserDefinedFileAttributeView.java#L247-L258 > > The same is now also done during `read()`. This should allow using arbitrary ByteBuffer implementations as `dst` and restores a certain symmetry between read and write. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3217 From github.com+741251+turbanoff at openjdk.java.net Mon Mar 29 13:34:27 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Mon, 29 Mar 2021 13:34:27 GMT Subject: Integrated: 8264029: Replace uses of StringBuffer with StringBuilder in java.base In-Reply-To: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com> Message-ID: On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov wrote: > Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'` > As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base` > Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679 This pull request has now been integrated. Changeset: fbbd98ba Author: Andrey Turbanov Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/fbbd98ba Stats: 12 lines in 3 files changed: 0 ins; 3 del; 9 mod 8264029: Replace uses of StringBuffer with StringBuilder in java.base Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/2922 From sebastian.stenzel at gmail.com Mon Mar 29 16:22:47 2021 From: sebastian.stenzel at gmail.com (Sebastian Stenzel) Date: Mon, 29 Mar 2021 18:22:47 +0200 Subject: RFR: JDK-8262958 (fs) UnixUserDefinedFileAttributeView cleanup In-Reply-To: References: Message-ID: <7B3BBCF7-188F-4B74-8655-74E778BD0F12@gmail.com> > On 26. Mar 2021, at 16:05, Sebastian Stenzel wrote: > > `flistxattr` gets called in two places: > 1. Obviously during `list()` > 2. When copying xattr from one file to another using `copyExtendedAttributes()` > > Commit 7104008 adds a new private method `List list(int fd, int bufSize) throws UnixException` that takes care of the "retry if buffer too small" logic that previously happened inside of two almost identical for-loops. > > In order to properly reuse the same code in both places, I move the stripping of the `USER_NAMESPACE` attr prefix from `asList` to `list()`, which I'd consider an undocumented side effect of the former anyway. > > This also significantly reduced complexity in both affected methods, but in turn `copyExtendedAttributes` will now deal with Strings instead of bytes for the attr names. While I am convinced that the benefits outweighs this point, I don't want to leave this unmentioned, as this change might slightly affect performance of `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)`. > > ------------- > > Commit messages: > - Merge branch 'master' into JDK-8262958 > - renamed variable > - Stream.toList() is already unmodifiable > - deduplicated flistxattr-related code > > Changes: https://git.openjdk.java.net/jdk/pull/2916/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2916&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8262958 > Stats: 95 lines in 1 file changed: 19 ins; 57 del; 19 mod > Patch: https://git.openjdk.java.net/jdk/pull/2916.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/2916/head:pull/2916 > > PR: https://git.openjdk.java.net/jdk/pull/2916 Alan, may I ask you to review this PR? As discussed earlier this month, I split up the scope into multiple small issues and changed the description of JDK-8262958. I didn't change the issue title yet (which might be confusing) because I'm not sure if bridgekeeper will understand what is happening. Let me know if I should adjust the title as well. Thank you! From brian.burkhalter at oracle.com Mon Mar 29 18:20:08 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 29 Mar 2021 18:20:08 +0000 Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v5] In-Reply-To: References: <5ji0UY3BcAwBuPxDjPmDJUFNTYmGfBi3HF3YizTUEmg=.199f436a-c373-4e79-90e6-c6c8b37e75b6@github.com> Message-ID: On Mar 27, 2021, at 8:57 AM, Alan Bateman > wrote: 8263898: Fix accidentally reverted copyright year The change looks okay. The test looks okay although there other cases that probably should be added at some point, in particular, FileChannel.open for reading, and AsynchronousFileChannel read & write. Added. test/jdk/java/nio/file/Files/NulDevice.java line 41: 39: public class NulDevice { 40: public static void main(final String[] args) throws IOException { 41: System.getProperties().list(System.out); Is the printing of the system properties a left-over? Yes, it is vestigial; removed. On Mar 28, 2021, at 8:24 AM, Alan Bateman > wrote: test/jdk/java/nio/file/Files/NulDevice.java line 47: 45: os.write(0x02); 46: System.out.printf("Wrote a byte to %s%n", path); 47: try (InputStream is = Files.newInputStream(path);) { One other test that you could add here is to test that available() returns 0. I've no doubt there are many file operations that will behavior in surprising ways when using the special "NUL" device if the common operations work in unsurprising ways then it would help. Added. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.java.net Mon Mar 29 18:25:54 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 29 Mar 2021 18:25:54 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v6] In-Reply-To: References: Message-ID: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8263898: Improve and clean up test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3183/files - new: https://git.openjdk.java.net/jdk/pull/3183/files/f799631d..7f356e97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=04-05 Stats: 43 lines in 1 file changed: 35 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3183/head:pull/3183 PR: https://git.openjdk.java.net/jdk/pull/3183 From alanb at openjdk.java.net Tue Mar 30 07:12:37 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 30 Mar 2021 07:12:37 GMT Subject: RFR: JDK-8262958 (fs) UnixUserDefinedFileAttributeView cleanup In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 16:36:06 GMT, Sebastian Stenzel wrote: > `flistxattr` gets called in two places: > 1. Obviously during `list()` > 2. When copying xattr from one file to another using `copyExtendedAttributes()` > > Commit 7104008 adds a new private method `List list(int fd, int bufSize) throws UnixException` that takes care of the "retry if buffer too small" logic that previously happened inside of two almost identical for-loops. > > In order to properly reuse the same code in both places, I move the stripping of the `USER_NAMESPACE` attr prefix from `asList` to `list()`, which I'd consider an undocumented side effect of the former anyway. > > This also significantly reduced complexity in both affected methods, but in turn `copyExtendedAttributes` will now deal with Strings instead of bytes for the attr names. While I am convinced that the benefits outweighs this point, I don't want to leave this unmentioned, as this change might slightly affect performance of `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)`. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2916 From alanb at openjdk.java.net Tue Mar 30 07:15:30 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 30 Mar 2021 07:15:30 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v6] In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 18:25:54 GMT, Brian Burkhalter wrote: >> This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8263898: Improve and clean up test Marked as reviewed by alanb (Reviewer). test/jdk/java/nio/file/Files/NulDevice.java line 64: > 62: > 63: try (final FileChannel ch = FileChannel.open(path, CREATE, > 64: TRUNCATE_EXISTING, WRITE)) { Did you mean to put a line break here? Same at L87. Asking because it would be easier to read if the open options were on the same line. If line length is the concern then you could drop the spurious "final" modifier. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From github.com+1204330+overheadhunter at openjdk.java.net Tue Mar 30 13:16:17 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Tue, 30 Mar 2021 13:16:17 GMT Subject: Integrated: JDK-8262958 (fs) UnixUserDefinedFileAttributeView cleanup In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 16:36:06 GMT, Sebastian Stenzel wrote: > `flistxattr` gets called in two places: > 1. Obviously during `list()` > 2. When copying xattr from one file to another using `copyExtendedAttributes()` > > Commit 7104008 adds a new private method `List list(int fd, int bufSize) throws UnixException` that takes care of the "retry if buffer too small" logic that previously happened inside of two almost identical for-loops. > > In order to properly reuse the same code in both places, I move the stripping of the `USER_NAMESPACE` attr prefix from `asList` to `list()`, which I'd consider an undocumented side effect of the former anyway. > > This also significantly reduced complexity in both affected methods, but in turn `copyExtendedAttributes` will now deal with Strings instead of bytes for the attr names. While I am convinced that the benefits outweighs this point, I don't want to leave this unmentioned, as this change might slightly affect performance of `Files.copy(src, dst, StandardCopyOption.COPY_ATTRIBUTES)`. This pull request has now been integrated. Changeset: daeca3ff Author: Sebastian Stenzel Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/daeca3ff Stats: 95 lines in 1 file changed: 19 ins; 57 del; 19 mod 8262958: (fs) UnixUserDefinedFileAttributeView cleanup Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/2916 From github.com+1204330+overheadhunter at openjdk.java.net Tue Mar 30 13:42:21 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Tue, 30 Mar 2021 13:42:21 GMT Subject: RFR: JDK-8264112 (fs) Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java Message-ID: Reordered fields and methods: First declare static variables, then instance variables, the constructor, methods. ------------- Commit messages: - reordered fields and methods Changes: https://git.openjdk.java.net/jdk/pull/3267/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3267&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264112 Stats: 26 lines in 1 file changed: 13 ins; 13 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3267.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3267/head:pull/3267 PR: https://git.openjdk.java.net/jdk/pull/3267 From bpb at openjdk.java.net Tue Mar 30 16:16:45 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 30 Mar 2021 16:16:45 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v7] In-Reply-To: References: Message-ID: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8263898: Remove final and link break ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3183/files - new: https://git.openjdk.java.net/jdk/pull/3183/files/7f356e97..71f3d345 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=05-06 Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3183/head:pull/3183 PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Tue Mar 30 16:16:45 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 30 Mar 2021 16:16:45 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v6] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 07:12:35 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: >> >> 8263898: Improve and clean up test > > test/jdk/java/nio/file/Files/NulDevice.java line 64: > >> 62: >> 63: try (final FileChannel ch = FileChannel.open(path, CREATE, >> 64: TRUNCATE_EXISTING, WRITE)) { > > Did you mean to put a line break here? Same at L87. Asking because it would be easier to read if the open options were on the same line. If line length is the concern then you could drop the spurious "final" modifier. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Tue Mar 30 16:39:33 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 30 Mar 2021 16:39:33 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v8] In-Reply-To: References: Message-ID: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8263898: Fix one more line break ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3183/files - new: https://git.openjdk.java.net/jdk/pull/3183/files/71f3d345..b6a51555 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3183&range=06-07 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3183/head:pull/3183 PR: https://git.openjdk.java.net/jdk/pull/3183 From alanb at openjdk.java.net Tue Mar 30 17:22:15 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 30 Mar 2021 17:22:15 GMT Subject: RFR: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) [v8] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 16:39:33 GMT, Brian Burkhalter wrote: >> This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8263898: Fix one more line break Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From alanb at openjdk.java.net Tue Mar 30 17:22:21 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 30 Mar 2021 17:22:21 GMT Subject: RFR: JDK-8264112 (fs) Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 13:28:59 GMT, Sebastian Stenzel wrote: > Reordered fields and methods: First declare static variables, then instance variables, the constructor, methods. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3267 From bpb at openjdk.java.net Tue Mar 30 18:21:17 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 30 Mar 2021 18:21:17 GMT Subject: Integrated: 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) In-Reply-To: References: Message-ID: <3BEL3UwziEiRbVgRIg3rZnF4RhlFlfStcgCQM1cVyGU=.81bf8952-c79b-4653-92a9-16fa335b870d@github.com> On Wed, 24 Mar 2021 23:45:16 GMT, Brian Burkhalter wrote: > This request proposes to change the native method `WindowsNativeDispatcher.SetEndOfFile()` to succeed even if the Windows function `SetEndOfFile()` returns zero if `GetFileSizeEx()` called on the handle succeeds and reveals a file size of zero. This pull request has now been integrated. Changeset: 353807c5 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/353807c5 Stats: 130 lines in 4 files changed: 125 ins; 0 del; 5 mod 8263898: (fs) Files.newOutputStream on the "NUL" special device throws FileSystemException: "nul: Incorrect function" (win) Reviewed-by: jpai, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3183 From bpb at openjdk.java.net Wed Mar 31 00:29:30 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 31 Mar 2021 00:29:30 GMT Subject: RFR: 8264400: (fs) WindowsFileStore equality depends on how the FileStore was constructed Message-ID: Please consider this change to make `sun.nio.fs.WindowsFileStore.equals()` return `true` if the root strings of the two objects are equal under case insensitive comparison, and the two `WindowsFileStore`s have the same volume information. ------------- Commit messages: - 8264400: (fs) WindowsFileStore equality depends on how the FileStore was constructed Changes: https://git.openjdk.java.net/jdk/pull/3279/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3279&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264400 Stats: 23 lines in 2 files changed: 19 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3279/head:pull/3279 PR: https://git.openjdk.java.net/jdk/pull/3279 From alanb at openjdk.java.net Wed Mar 31 10:38:09 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 31 Mar 2021 10:38:09 GMT Subject: RFR: 8264400: (fs) WindowsFileStore equality depends on how the FileStore was constructed In-Reply-To: References: Message-ID: <_5Q_jfIcOJWwzGR1RyPYU4Twct04KvrlgH-nNRWrHnw=.33da8810-101f-47f2-8c5a-e5b891e110ac@github.com> On Wed, 31 Mar 2021 00:22:20 GMT, Brian Burkhalter wrote: > Please consider this change to make `sun.nio.fs.WindowsFileStore.equals()` return `true` if the root strings of the two objects are equal under case insensitive comparison, and the two `WindowsFileStore`s have the same volume information. src/java.base/windows/classes/sun/nio/fs/WindowsFileStore.java line 243: > 241: volInfo.volumeSerialNumber() == otherInfo.volumeSerialNumber(); > 242: } > 243: return false; The volType == DRIVE_REMOTE case is the reason why we didn't fix this one in the past. Can you summarise that the VolumeInfomation is for this case? ------------- PR: https://git.openjdk.java.net/jdk/pull/3279 From github.com+1204330+overheadhunter at openjdk.java.net Wed Mar 31 10:42:24 2021 From: github.com+1204330+overheadhunter at openjdk.java.net (Sebastian Stenzel) Date: Wed, 31 Mar 2021 10:42:24 GMT Subject: Integrated: JDK-8264112 (fs) Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java In-Reply-To: References: Message-ID: <3uQh2OOOvTCxGtt54KfOmusAMadFE7mrWbv4dO6sZfo=.957c0286-a45f-4e86-bb1c-e62a4878a941@github.com> On Tue, 30 Mar 2021 13:28:59 GMT, Sebastian Stenzel wrote: > Reordered fields and methods: First declare static variables, then instance variables, the constructor, methods. This pull request has now been integrated. Changeset: 604b14c4 Author: Sebastian Stenzel Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/604b14c4 Stats: 26 lines in 1 file changed: 13 ins; 13 del; 0 mod 8264112: (fs) Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/3267 From cgo at openjdk.java.net Wed Mar 31 10:57:26 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Wed, 31 Mar 2021 10:57:26 GMT Subject: RFR: 8264502: FileDispatcherImpl_setDirect0 might return uninitialized variable Message-ID: Hi, please review this small patch which fixes a possible return of an uninitialized variable. Thanks, Christoph ------------- Commit messages: - 8264502: FileDispatcherImpl_setDirect0 might return uninitialized variable Changes: https://git.openjdk.java.net/jdk/pull/3284/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3284&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264502 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3284/head:pull/3284 PR: https://git.openjdk.java.net/jdk/pull/3284 From alanb at openjdk.java.net Wed Mar 31 11:08:25 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 31 Mar 2021 11:08:25 GMT Subject: RFR: 8264502: FileDispatcherImpl_setDirect0 might return uninitialized variable In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 10:50:56 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this small patch which fixes a possible return of an uninitialized variable. > > Thanks, > Christoph src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c line 378: > 376: } > 377: #else > 378: result = -1; This looks okay but can you add to the bug or the PR as to how you ran into this, is this a port to some platform that doesn't support it? ------------- PR: https://git.openjdk.java.net/jdk/pull/3284 From cgo at openjdk.java.net Wed Mar 31 11:14:30 2021 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Wed, 31 Mar 2021 11:14:30 GMT Subject: RFR: 8264502: FileDispatcherImpl_setDirect0 might return uninitialized variable In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 11:05:38 GMT, Alan Bateman wrote: >> Hi, >> >> please review this small patch which fixes a possible return of an uninitialized variable. >> >> Thanks, >> Christoph > > src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c line 378: > >> 376: } >> 377: #else >> 378: result = -1; > > This looks okay but can you add to the bug or the PR as to how you ran into this, is this a port to some platform that doesn't support it? I made a comment in the bug report. ------------- PR: https://git.openjdk.java.net/jdk/pull/3284 From alanb at openjdk.java.net Wed Mar 31 12:06:34 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 31 Mar 2021 12:06:34 GMT Subject: RFR: 8264502: FileDispatcherImpl_setDirect0 might return uninitialized variable In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 10:50:56 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this small patch which fixes a possible return of an uninitialized variable. > > Thanks, > Christoph Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3284 From alanb at openjdk.java.net Wed Mar 31 12:06:34 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 31 Mar 2021 12:06:34 GMT Subject: RFR: 8264502: FileDispatcherImpl_setDirect0 might return uninitialized variable In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 11:11:06 GMT, Christoph G?ttschkes wrote: >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c line 378: >> >>> 376: } >>> 377: #else >>> 378: result = -1; >> >> This looks okay but can you add to the bug or the PR as to how you ran into this, is this a port to some platform that doesn't support it? > > I made a comment in the bug report. Thanks, I guessed there must be a new port in the picture as this case is not compiled in for any of the main stream platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/3284 From bpb at openjdk.java.net Wed Mar 31 15:39:20 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 31 Mar 2021 15:39:20 GMT Subject: RFR: 8264400: (fs) WindowsFileStore equality depends on how the FileStore was constructed In-Reply-To: <_5Q_jfIcOJWwzGR1RyPYU4Twct04KvrlgH-nNRWrHnw=.33da8810-101f-47f2-8c5a-e5b891e110ac@github.com> References: <_5Q_jfIcOJWwzGR1RyPYU4Twct04KvrlgH-nNRWrHnw=.33da8810-101f-47f2-8c5a-e5b891e110ac@github.com> Message-ID: <4vGA2Y0_MbgbHRsedaxBpyEFx0UqluLvm6zmgSipav4=.27955baf-1195-42d4-becc-34c30bbd20be@github.com> On Wed, 31 Mar 2021 10:35:42 GMT, Alan Bateman wrote: >> Please consider this change to make `sun.nio.fs.WindowsFileStore.equals()` return `true` if the root strings of the two objects are equal under case insensitive comparison, and the two `WindowsFileStore`s have the same volume information. > > src/java.base/windows/classes/sun/nio/fs/WindowsFileStore.java line 243: > >> 241: volInfo.volumeSerialNumber() == otherInfo.volumeSerialNumber(); >> 242: } >> 243: return false; > > The volType == DRIVE_REMOTE case is the reason why we didn't fix this one in the past. Can you summarise that the VolumeInfomation is for this case? I was not able to test that case yet. Using the VolumeInformation was intended to limit spurious equality. Can you explain abut DRIVE_REMOTE? ------------- PR: https://git.openjdk.java.net/jdk/pull/3279 From bpb at openjdk.java.net Wed Mar 31 15:49:07 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 31 Mar 2021 15:49:07 GMT Subject: RFR: 8264502: (fc) FileDispatcherImpl.setDirect0 might return uninitialized variable on some platforms In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 10:50:56 GMT, Christoph G?ttschkes wrote: > Hi, > > please review this small patch which fixes a possible return of an uninitialized variable. > > Thanks, > Christoph Approved modulo updating the copyright year. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3284 From bpb at openjdk.java.net Wed Mar 31 20:29:51 2021 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 31 Mar 2021 20:29:51 GMT Subject: RFR: 8264539: Improve failure message of java/nio/file/WatchService/SensitivityModifier.java Message-ID: Please consider this request to improve the message printed when no `ENTRY_MODIFY` events are received. In the polling implementation of `WatchService` currently used on macOS, it would be useful to know the sensitivity of polling in effect for the failing case. It might indicate, for example, that low sensitivity should not be used in the test. ------------- Commit messages: - 8264539: Improve failure message of java/nio/file/WatchService/SensitivityModifier.java Changes: https://git.openjdk.java.net/jdk/pull/3290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3290&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264539 Stats: 22 lines in 1 file changed: 15 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3290/head:pull/3290 PR: https://git.openjdk.java.net/jdk/pull/3290