From christoph.langer at sap.com Mon Oct 1 06:46:54 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 1 Oct 2018 06:46:54 +0000 Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and permissions of the files In-Reply-To: <5BAF0CD6.90803@oracle.com> References: <5BAF0CD6.90803@oracle.com> Message-ID: Hi Sherman, thanks for getting back and bringing up these points. > (1) There is a "masked" security concern regarding adding the > "ownership/permission" into the jar file. > > "Security concern: > > The current signed jar spec only protects the name and content of the jar > entries. If any extra info is added, its value will not be used in the > signing/verifying process. This means anyone can change these info in a > signed jar and the user has no way to check if the file is genuine." I didn't know that. However, as the default behavior does not change, these permission bits will not be propagated/used, unless the developer uses the API or the user of the jar tool enables the new option. One should probably add comments about this signing issue in the documentation then. Is there any way to augment jar signing to (conditionally?) include the external attributes field? > (2) Regarding the implementation whats the motivation of use the high byte > of the "external file > attributes" vs to use the info-zip as suggested in the report? I've not looked > into zip/unzip > implementation, which one is zip/unzip using? > > "A group known as INFO-zip has devised a number of different extensions > for ZIP for Unix. Their first and second extension attempts added > support for UID and GID but not permissions. The third Unix extension, > also known as the "ASi" or "un" extension, provides for file permissions > and symlinks also. These extensions have become de-facto standards, > and have not changed now since 1996." I'm not aware of a document of specification for the INFO-zip extensions regarding UID, GID and even permissions. Maybe you can share this with me. But I've checked InfoZip's Zip and UnZip sources at https://sourceforge.net/projects/infozip/files/ and found they're using the CENATX field ( >> 16) like my patch does. Best regards Christoph From brian.burkhalter at oracle.com Tue Oct 2 22:19:09 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 2 Oct 2018 15:19:09 -0700 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> Message-ID: <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> Hi Lucy, A few minor comments. RdmaPollSelectorImpl - The imported ?Unsafe? is not used. In general any unused imports and #includes should be removed. LinuxRdmaSocketDispatcherImpl.preClose0() - The native function eventually invoked is empty. Perhaps LinuxRdmaSocketDispatcherImpl.preClose() could just be made a no-op and preClose0() removed? RdmaNet.isRdmaAvailable0() - Commented-out lines 59-61 should be deleted. Otherwise, I ran this through our build and test system and there were no issues with version 12. Thanks, Brian On Sep 29, 2018, at 8:59 PM, Lu, Yingqi wrote: > Please find version 12 of the patch available at http://cr.openjdk.java.net/~ylu/8195160.12. I tested on my local Linux machine without any RDMA devices. The issue with the two test cases is resolved. Please review and let me know if you see anything else is missing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Wed Oct 3 23:42:25 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Wed, 3 Oct 2018 23:42:25 +0000 Subject: adding rsockets support into JDK In-Reply-To: <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> Hi Brian, Here is the version 13 of the patch. http://cr.openjdk.java.net/~ylu/8195160.13 In this version, I fixed the items you mentioned in your previous email. In addition, I went through all the files and removed additional imports/#includes. I also extended the Copyright year range to 2018 on the changed files. For all the newly added files especially test cases, I did "Copyright (c) 2018" even though some of content are copied from other regular socket or socket channel related test cases. Please let me know if this is the right way to do it. Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Tuesday, October 2, 2018 3:19 PM To: Lu, Yingqi Cc: Aundhe, Shirish ; nio-dev at openjdk.java.net; Viswanathan, Sandhya ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, A few minor comments. RdmaPollSelectorImpl - The imported "Unsafe" is not used. In general any unused imports and #includes should be removed. LinuxRdmaSocketDispatcherImpl.preClose0() - The native function eventually invoked is empty. Perhaps LinuxRdmaSocketDispatcherImpl.preClose() could just be made a no-op and preClose0() removed? RdmaNet.isRdmaAvailable0() - Commented-out lines 59-61 should be deleted. Otherwise, I ran this through our build and test system and there were no issues with version 12. Thanks, Brian On Sep 29, 2018, at 8:59 PM, Lu, Yingqi > wrote: Please find version 12 of the patch available at http://cr.openjdk.java.net/~ylu/8195160.12. I tested on my local Linux machine without any RDMA devices. The issue with the two test cases is resolved. Please review and let me know if you see anything else is missing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Wed Oct 3 23:44:56 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Oct 2018 16:44:56 -0700 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> Message-ID: <4BB47C28-FFB3-4C06-B24D-DFFFB1F47477@oracle.com> Hi Lucy, > On Oct 3, 2018, at 4:42 PM, Lu, Yingqi wrote: > > Here is the version 13 of the patch. http://cr.openjdk.java.net/~ylu/8195160.13 Thanks, I?ll take a look. > In this version, I fixed the items you mentioned in your previous email. > > In addition, I went through all the files and removed additional imports/#includes. Sounds good. > I also extended the Copyright year range to 2018 on the changed files. For all the newly added files especially test cases, I did ?Copyright (c) 2018? even though some of content are copied from other regular socket or socket channel related test cases. Please let me know if this is the right way to do it. That seems fine to me. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Thu Oct 4 00:02:08 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 4 Oct 2018 00:02:08 +0000 Subject: adding rsockets support into JDK In-Reply-To: <4BB47C28-FFB3-4C06-B24D-DFFFB1F47477@oracle.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> <4BB47C28-FFB3-4C06-B24D-DFFFB1F47477@oracle.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1538AF4@ORSMSX113.amr.corp.intel.com> Hi Brian, Thank you for all the help here! I also modified the CSR at https://bugs.openjdk.java.net/browse/JDK-8205186 by adding following lines to the end of it. I think we need to include all the API changes here? In addition, we will change the access modifier on the following methods: java.net.ServerSocket: ServerSocket(SocketImpl impl) from package private to protected java.net.SocketImpl: setSocket(Socket soc) and setServerSocket(ServerSocket soc) from package private to protected Please review and let me know if there is anything missing. Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Wednesday, October 3, 2018 4:45 PM To: Lu, Yingqi Cc: Aundhe, Shirish ; nio-dev at openjdk.java.net; Viswanathan, Sandhya ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, On Oct 3, 2018, at 4:42 PM, Lu, Yingqi > wrote: Here is the version 13 of the patch. http://cr.openjdk.java.net/~ylu/8195160.13 Thanks, I?ll take a look. In this version, I fixed the items you mentioned in your previous email. In addition, I went through all the files and removed additional imports/#includes. Sounds good. I also extended the Copyright year range to 2018 on the changed files. For all the newly added files especially test cases, I did ?Copyright (c) 2018? even though some of content are copied from other regular socket or socket channel related test cases. Please let me know if this is the right way to do it. That seems fine to me. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Oct 4 00:17:35 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 3 Oct 2018 17:17:35 -0700 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1538AF4@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> <4BB47C28-FFB3-4C06-B24D-DFFFB1F47477@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538AF4@ORSMSX113.amr.corp.intel.com> Message-ID: Hi Lucy, > On Oct 3, 2018, at 5:02 PM, Lu, Yingqi wrote: > > Thank you for all the help here! > > I also modified the CSR athttps://bugs.openjdk.java.net/browse/JDK-8205186 by adding following lines to the end of it. I think we need to include all the API changes here? Yes, all visible API changes need to be included. > > In addition, we will change the access modifier on the following methods: > > java.net.ServerSocket: ServerSocket(SocketImpl impl) from package private to protected > > java.net.SocketImpl: setSocket(Socket soc) and setServerSocket(ServerSocket soc) from package private to protected On these latter two items, I recall that Alan had an objection: "On the API changes then I see that two protected setXXXX methods have been added to SocketImpl. I think we should try to avoid that, even if it means using the shared secrets mechanism.? [1] > Please review and let me know if there is anything missing. Will do. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-August/005393.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Thu Oct 4 22:28:50 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Thu, 4 Oct 2018 22:28:50 +0000 Subject: adding rsockets support into JDK In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> <4BB47C28-FFB3-4C06-B24D-DFFFB1F47477@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538AF4@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1539EE1@ORSMSX113.amr.corp.intel.com> Hi Brian, Please find version 14 of the patch available at http://cr.openjdk.java.net/~ylu/8195160.14/ In this version, I use shared secrets mechanism to avoid changing two setXXX methods from ?package private? to ?protected? in SocketImpl. Please review and let me know if this is a reasonable change. I also modified CSR accordingly at https://bugs.openjdk.java.net/browse/JDK-8205186. Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Wednesday, October 3, 2018 5:18 PM To: Lu, Yingqi Cc: Aundhe, Shirish ; nio-dev at openjdk.java.net; Viswanathan, Sandhya ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, On Oct 3, 2018, at 5:02 PM, Lu, Yingqi > wrote: Thank you for all the help here! I also modified the CSR athttps://bugs.openjdk.java.net/browse/JDK-8205186 by adding following lines to the end of it. I think we need to include all the API changes here? Yes, all visible API changes need to be included. In addition, we will change the access modifier on the following methods: java.net.ServerSocket: ServerSocket(SocketImpl impl) from package private to protected java.net.SocketImpl: setSocket(Socket soc) and setServerSocket(ServerSocket soc) from package private to protected On these latter two items, I recall that Alan had an objection: "On the API changes then I see that two protected setXXXX methods have been added to SocketImpl. I think we should try to avoid that, even if it means using the shared secrets mechanism.? [1] Please review and let me know if there is anything missing. Will do. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/nio-dev/2018-August/005393.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Oct 5 21:43:17 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Oct 2018 14:43:17 -0700 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1539EE1@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> <4BB47C28-FFB3-4C06-B24D-DFFFB1F47477@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538AF4@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1539EE1@ORSMSX113.amr.corp.intel.com> Message-ID: Hi Lucy, This version appears to be missing a class ?jdk.internal.misc.JdkRdmaSocketImplAccess? [1]. Did you accidentally omit doing an ?hg add? before refreshing the patch? Thanks, Brian > On Oct 4, 2018, at 3:28 PM, Lu, Yingqi wrote: > > Please find version 14 of the patch available at http://cr.openjdk.java.net/~ylu/8195160.14/ [1] /home/bpb/Work/openjdk/src/java.base/share/classes/java/net/SocketImpl.java:33: error: cannot find symbol import jdk.internal.misc.JdkRdmaSocketImplAccess; ^ symbol: class JdkRdmaSocketImplAccess location: package jdk.internal.misc /home/bpb/Work/openjdk/src/java.base/share/classes/java/net/SocketImpl.java:74: error: cannot find symbol private static final JdkRdmaSocketImplAccess rsiAccess = ^ symbol: class JdkRdmaSocketImplAccess location: class SocketImpl /home/bpb/Work/openjdk/src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java:76: error: cannot find symbol private static JdkRdmaSocketImplAccess jdkRdmaSocketImplAccess; ^ symbol: class JdkRdmaSocketImplAccess location: class SharedSecrets /home/bpb/Work/openjdk/src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java:341: error: cannot find symbol public static void setJdkRdmaSocketImplAccess(JdkRdmaSocketImplAccess jrsia) { ^ symbol: class JdkRdmaSocketImplAccess location: class SharedSecrets /home/bpb/Work/openjdk/src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java:345: error: cannot find symbol public static JdkRdmaSocketImplAccess getJdkRdmaSocketImplAccess() { ^ symbol: class JdkRdmaSocketImplAccess location: class SharedSecrets 5 errors CompileJavaModules.gmk:594: recipe for target '/home/bpb/Work/openjdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch' failed make[3]: *** [/home/bpb/Work/openjdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Oct 5 21:53:53 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Oct 2018 14:53:53 -0700 Subject: Remove jdk/java/nio/channels/Selector/RacyDeregister.java from problem list Message-ID: <8C21F6D5-DC73-4158-B69F-6EF804243CED@oracle.com> With jtreg4.2-b13 in place, test output lost because of a timeout is more likely to be captured. It would be good to remove this test from the problem list so that it can fail and any such trapped output examined. Thanks, Brian Bug: https://bugs.openjdk.java.net/browse/JDK-8211794 Diff: --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -565,7 +565,6 @@ java/nio/channels/DatagramChannel/ChangingAddress.java 7141822 macosx-all java/nio/channels/Selector/Wakeup.java 6963118 windows-all -java/nio/channels/Selector/RacyDeregister.java 8201765 windows-all java/nio/file/WatchService/Basic.java 7158947 solaris-all Solaris 11 java/nio/file/WatchService/MayFlies.java 7158947 solaris-all Solaris 11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brent.christian at oracle.com Fri Oct 5 22:18:19 2018 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 5 Oct 2018 15:18:19 -0700 Subject: Remove jdk/java/nio/channels/Selector/RacyDeregister.java from problem list In-Reply-To: <8C21F6D5-DC73-4158-B69F-6EF804243CED@oracle.com> References: <8C21F6D5-DC73-4158-B69F-6EF804243CED@oracle.com> Message-ID: <4c034db6-b07e-9aed-00c1-b34d2731f8c9@oracle.com> Sounds good, -Brent On 10/5/18 2:53 PM, Brian Burkhalter wrote: > With jtreg4.2-b13 in place, test output lost because of a timeout is > more likely to be captured. It would be good to remove this test from > the problem list so that it can fail and any such trapped output examined. > > Thanks, > > Brian > Bug:https://bugs.openjdk.java.net/browse/JDK-8211794 > > Diff: > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -565,7 +565,6 @@ > ?java/nio/channels/DatagramChannel/ChangingAddress.java > 7141822 macosx-all > > > ?java/nio/channels/Selector/Wakeup.java > 6963118 windows-all > -java/nio/channels/Selector/RacyDeregister.java? ? ? ? ? ? ? ? ? 8201765 > windows-all > > > ?java/nio/file/WatchService/Basic.java > 7158947 solaris-all Solaris 11 > ?java/nio/file/WatchService/MayFlies.java > 7158947 solaris-all Solaris 11 From yingqi.lu at intel.com Fri Oct 5 22:45:19 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 5 Oct 2018 22:45:19 +0000 Subject: adding rsockets support into JDK In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> <4BB47C28-FFB3-4C06-B24D-DFFFB1F47477@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538AF4@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1539EE1@ORSMSX113.amr.corp.intel.com>, Message-ID: Hi Brian, My bad!! I must forget to add it into hg before refreshing the patch. I will update the patch tonight. Thank you for letting me know! Thanks, Lucy Sent from my iPhone On Oct 5, 2018, at 2:44 PM, Brian Burkhalter > wrote: Hi Lucy, This version appears to be missing a class ?jdk.internal.misc.JdkRdmaSocketImplAccess? [1]. Did you accidentally omit doing an ?hg add? before refreshing the patch? Thanks, Brian On Oct 4, 2018, at 3:28 PM, Lu, Yingqi > wrote: Please find version 14 of the patch available at http://cr.openjdk.java.net/~ylu/8195160.14/ [1] /home/bpb/Work/openjdk/src/java.base/share/classes/java/net/SocketImpl.java:33: error: cannot find symbol import jdk.internal.misc.JdkRdmaSocketImplAccess; ^ symbol: class JdkRdmaSocketImplAccess location: package jdk.internal.misc /home/bpb/Work/openjdk/src/java.base/share/classes/java/net/SocketImpl.java:74: error: cannot find symbol private static final JdkRdmaSocketImplAccess rsiAccess = ^ symbol: class JdkRdmaSocketImplAccess location: class SocketImpl /home/bpb/Work/openjdk/src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java:76: error: cannot find symbol private static JdkRdmaSocketImplAccess jdkRdmaSocketImplAccess; ^ symbol: class JdkRdmaSocketImplAccess location: class SharedSecrets /home/bpb/Work/openjdk/src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java:341: error: cannot find symbol public static void setJdkRdmaSocketImplAccess(JdkRdmaSocketImplAccess jrsia) { ^ symbol: class JdkRdmaSocketImplAccess location: class SharedSecrets /home/bpb/Work/openjdk/src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java:345: error: cannot find symbol public static JdkRdmaSocketImplAccess getJdkRdmaSocketImplAccess() { ^ symbol: class JdkRdmaSocketImplAccess location: class SharedSecrets 5 errors CompileJavaModules.gmk:594: recipe for target '/home/bpb/Work/openjdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch' failed make[3]: *** [/home/bpb/Work/openjdk/build/linux-x86_64-server-release/jdk/modules/java.base/_the.java.base_batch] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Oct 5 22:56:30 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 Oct 2018 15:56:30 -0700 Subject: adding rsockets support into JDK In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AD12E2D13@fmsmsx158.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1475CB5@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1477F70@ORSMSX113.amr.corp.intel.com> <68b04ce0-6a16-6b23-3b62-1a400cba1b8a@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147CD89@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD147E550@ORSMSX113.amr.corp.intel.com> <583d2e38-94c1-9c38-d89d-de17e4e3f7c6@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD148A306@ORSMSX113.amr.corp.intel.com> <10aca7c2-340b-dbb9-6da9-750bd603c403@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD14EB9BC@ORSMSX113.amr.corp.intel.com> <39c952af-8e62-2774-11c6-cc1221964b64@oracle.com> <2E9E08D0-B232-4DFE-9EE6-468D06B715A5@oracle.com> <4003426e-1e73-a7b1-a5a3-5006f01fcab3@oracle.com> <0f35e51e-8297-2fe1-fd6f! ! ! ! ! -90d5c464e6bc@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD151C7F8@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152A195@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD152B5C5@ORSMSX113.amr.corp.intel.com> <13D9EA95-E63B-4764-BC33-27098D1BE48C@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD15306CB@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1531734@ORSMSX113.amr.corp.intel.com> <6E3FF87F-8DAA-4444-96AA-8210C58B5259@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538A72@ORSMSX113.amr.corp.intel.com> <4BB47C28-FFB3-4C06-B24D-DFFFB1F47477@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1538AF4@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1539EE1@ORSMSX113.amr.corp.intel.com> Message-ID: Hi Lucy, No worries: I?ve done the same myself. No hurry on my side to see it before Monday. Thanks, Brian > On Oct 5, 2018, at 3:45 PM, Lu, Yingqi wrote: > > My bad!! I must forget to add it into hg before refreshing the patch. > > I will update the patch tonight. > > Thank you for letting me know! -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Sat Oct 6 03:23:15 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Sat, 6 Oct 2018 03:23:15 +0000 Subject: adding rsockets support into JDK In-Reply-To: References: Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD153B4C7@ORSMSX113.amr.corp.intel.com> Hi Brian, The link http://cr.openjdk.java.net/~ylu/8195160.14/ is updated with the additional file jdk.internal.misc.JdkRdmaSocketImplAccess.java. It might be just me, but I needed to refresh both pages http://cr.openjdk.java.net/~ylu/8195160.14/ and http://cr.openjdk.java.net/~ylu/8195160.14/jdk12-8195160-version14.patch to get the updated content. Please let me know if you see any issues. Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Friday, October 5, 2018 3:57 PM To: Lu, Yingqi Cc: Aundhe, Shirish ; nio-dev at openjdk.java.net; Viswanathan, Sandhya ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, No worries: I?ve done the same myself. No hurry on my side to see it before Monday. Thanks, Brian On Oct 5, 2018, at 3:45 PM, Lu, Yingqi > wrote: My bad!! I must forget to add it into hg before refreshing the patch. I will update the patch tonight. Thank you for letting me know! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.wth at gmail.com Wed Oct 10 11:31:49 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Wed, 10 Oct 2018 13:31:49 +0200 Subject: Using NIO2 for writing zip file entries without corresponding folder entries Message-ID: Hi, I was wondering why the ZipFileSystem checked for the existence of a file's parents before writing a file. Writing folder entries is not a requirement in the specification for zip files and I find it strange that the implementation enforces it. I found that even to be problematic when altering a zip file where NIO2 requires you to add folder entries that did not exist before. Thanks for the information. Best regards, Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.rappo at oracle.com Wed Oct 10 11:46:53 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 10 Oct 2018 12:46:53 +0100 Subject: RFR [12] 8212000: Verify exported symbols in java.base (libnet, libnio/ch) Message-ID: Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8212000/webrev.00/8212000/ This is a clean-up kind of change. It seals unnecessarily exported functions from libnet and libnio, and also removes an unused declaration from libnet. This change has been built and tested on all supported platforms. Thanks, -Pavel From Alan.Bateman at oracle.com Wed Oct 10 11:50:37 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2018 12:50:37 +0100 Subject: Using NIO2 for writing zip file entries without corresponding folder entries In-Reply-To: References: Message-ID: On 10/10/2018 12:31, Rafael Winterhalter wrote: > Hi, > > I was wondering why the ZipFileSystem checked for the existence of a > file's parents before writing a file. Writing folder entries is not a > requirement in the specification for zip files and I find it strange > that the implementation enforces it. I found that even to be > problematic when altering a zip file where NIO2 requires you to add > folder entries that did not exist before. > If you using a zip file system to create a new zip file then it shouldn't be a surprise that you need to create a directory before creating entries in the directory. The zip file system is just trying to behave like a regular file system. The zip file system provider does lack a configuration option to strip directories when writing, that could potentially be added if important. One other thing is that the zip file system provider can open existing zip files that don't have entries for directories, it's should emulate them for that scenario. -Alan. From rafael.wth at gmail.com Wed Oct 10 12:00:10 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Wed, 10 Oct 2018 14:00:10 +0200 Subject: Using NIO2 for writing zip file entries without corresponding folder entries In-Reply-To: References: Message-ID: You are right with that it does emulate missing folders in the source file. I have a use case where I patch a zip file with some additional entries that are placed in directories of files that already exist in the zip file. To do so, I have to add the directories for the added files. Doing so confuses the processing backend which does not filter the folder entries but treats them as normal files which causes this processor to crash when treating them as regular files. I understand that the file system abstraction mandates folders but for zip files, I would find it practical if it was possible to write files without demanding folders for them. The current work around is to write a whole new file with ZipInputStream/ZipOutputStream and to copy all existing entries what adds quite a bit of I/O overhead. Therefore, I would welcome the mentioned feature. Thanks for the explanation, best regards, Rafael Am Mi., 10. Okt. 2018 um 13:50 Uhr schrieb Alan Bateman < Alan.Bateman at oracle.com>: > On 10/10/2018 12:31, Rafael Winterhalter wrote: > > Hi, > > > > I was wondering why the ZipFileSystem checked for the existence of a > > file's parents before writing a file. Writing folder entries is not a > > requirement in the specification for zip files and I find it strange > > that the implementation enforces it. I found that even to be > > problematic when altering a zip file where NIO2 requires you to add > > folder entries that did not exist before. > > > If you using a zip file system to create a new zip file then it > shouldn't be a surprise that you need to create a directory before > creating entries in the directory. The zip file system is just trying to > behave like a regular file system. The zip file system provider does > lack a configuration option to strip directories when writing, that > could potentially be added if important. > > One other thing is that the zip file system provider can open existing > zip files that don't have entries for directories, it's should emulate > them for that scenario. > > -Alan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Oct 10 12:58:56 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2018 13:58:56 +0100 Subject: Using NIO2 for writing zip file entries without corresponding folder entries In-Reply-To: References: Message-ID: <9d401812-2704-7cb2-d57c-c8ea6efa32e7@oracle.com> On 10/10/2018 13:00, Rafael Winterhalter wrote: > You are right with that it does emulate missing folders in the source > file. > > I have a use case where I patch a zip file with some additional > entries that are placed in directories of files that already exist in > the zip file. To do so, I have to add the directories for the added files. I just tried a quick test with a zip file containing one entry x/foo.txt (created with zip -D to not create directory entries). With the zip file system then I replaced x/foo.txt, then a second test to create x/bar.txt and I didn't see any issues. Is that close to what you are doing? I suspect most usages of the zip file system provider are read-only (javac being the biggest user) and it's possible there are issues or short comings when writing or updating that haven't come up. If you can provides the instructions or a simple test case to show what you are seeing then it would be useful. Also which JDK release is this? > Doing so confuses the processing backend which does not filter the > folder entries but treats them as normal files which causes this > processor to crash when treating them as regular files. This sounds like a bug in whatever this system is as many zip tools will create directory entries by default. -Alan From Alan.Bateman at oracle.com Wed Oct 10 13:04:51 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2018 14:04:51 +0100 Subject: RFR [12] 8212000: Verify exported symbols in java.base (libnet, libnio/ch) In-Reply-To: References: Message-ID: On 10/10/2018 12:46, Pavel Rappo wrote: > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8212000/webrev.00/8212000/ > > This is a clean-up kind of change. It seals unnecessarily exported functions > from libnet and libnio, and also removes an unused declaration from libnet. > This change has been built and tested on all supported platforms. > I suspect handleSocketError was exported at some point for SCTP but libsctp has its own implementation now. So I think the changes look okay, assuming you've built and tested all platforms. -Alan From chris.hegarty at oracle.com Wed Oct 10 13:20:56 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 10 Oct 2018 14:20:56 +0100 Subject: RFR [12] 8212000: Verify exported symbols in java.base (libnet, libnio/ch) In-Reply-To: References: Message-ID: <9e7ec000-b3e9-066c-6ebb-313cf53de4b2@oracle.com> On 10/10/18 12:46, Pavel Rappo wrote: > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8212000/webrev.00/8212000/ This looks ok to me. -Chris. From brian.burkhalter at oracle.com Mon Oct 15 23:57:47 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Oct 2018 16:57:47 -0700 Subject: 8212212: (bf) Incorrect path to stream preprocessor source in java.nio Buffer test scripts Message-ID: <26FC35A6-8C12-42E1-A8C3-21B3C2F62084@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8212212 http://cr.openjdk.java.net/~bpb/8212212/webrev.00/ Please review this simple change. Thanks, Brian From Alan.Bateman at oracle.com Tue Oct 16 06:34:35 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Oct 2018 07:34:35 +0100 Subject: 8212212: (bf) Incorrect path to stream preprocessor source in java.nio Buffer test scripts In-Reply-To: <26FC35A6-8C12-42E1-A8C3-21B3C2F62084@oracle.com> References: <26FC35A6-8C12-42E1-A8C3-21B3C2F62084@oracle.com> Message-ID: <3f700851-041a-e334-02b9-bc0fee03d3cc@oracle.com> On 16/10/2018 00:57, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8212212 > http://cr.openjdk.java.net/~bpb/8212212/webrev.00/ > > Please review this simple change. > Looks good. -Alan From rafael.wth at gmail.com Tue Oct 16 13:00:11 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 16 Oct 2018 15:00:11 +0200 Subject: Using NIO2 for writing zip file entries without corresponding folder entries In-Reply-To: <9d401812-2704-7cb2-d57c-c8ea6efa32e7@oracle.com> References: <9d401812-2704-7cb2-d57c-c8ea6efa32e7@oracle.com> Message-ID: Hi Alan, you are right about being allowed to reuse an existing directory, my use case is however slighty different. It is about bundeling several zip files into a single file: Path sample = Files.createTempFile("source", ".zip"); Path other = Files.createTempFile("target", ".zip"); // Emulate original input try (ZipOutputStream outputStream = new ZipOutputStream(Files.newOutputStream(sample))) { outputStream.putNextEntry(new ZipEntry("foo/bar.txt")); outputStream.write(new byte[] { 1, 2, 3 }); outputStream.closeEntry(); } try (ZipOutputStream outputStream = new ZipOutputStream(Files.newOutputStream(other))) { outputStream.putNextEntry(new ZipEntry("qux/baz.txt")); outputStream.write(new byte[] { 4, 5, 6 }); outputStream.closeEntry(); } // Emulate merging two zip files without directories using NIO2 try ( FileSystem source = FileSystems.newFileSystem(sample, null); FileSystem target = FileSystems.newFileSystem(other, null) ) { Path path = source.getPath("foo/bar.txt"); Files.copy(path, target.getPath(source.toString())); } It surprised me that this does not work when trying to migrate from ZipInputStream to NIO2. And yes, you are absolutely right about the target system that is processing the file is the actual problem. It is running on a mainframe that nobody wants to touch anymore, however, so we are stuck with worarounds. Thanks for your input! Best regards, Rafael Am Mi., 10. Okt. 2018 um 14:59 Uhr schrieb Alan Bateman < Alan.Bateman at oracle.com>: > On 10/10/2018 13:00, Rafael Winterhalter wrote: > > You are right with that it does emulate missing folders in the source > > file. > > > > I have a use case where I patch a zip file with some additional > > entries that are placed in directories of files that already exist in > > the zip file. To do so, I have to add the directories for the added > files. > I just tried a quick test with a zip file containing one entry x/foo.txt > (created with zip -D to not create directory entries). With the zip file > system then I replaced x/foo.txt, then a second test to create x/bar.txt > and I didn't see any issues. Is that close to what you are doing? I > suspect most usages of the zip file system provider are read-only (javac > being the biggest user) and it's possible there are issues or short > comings when writing or updating that haven't come up. If you can > provides the instructions or a simple test case to show what you are > seeing then it would be useful. Also which JDK release is this? > > > Doing so confuses the processing backend which does not filter the > > folder entries but treats them as normal files which causes this > > processor to crash when treating them as regular files. > This sounds like a bug in whatever this system is as many zip tools will > create directory entries by default. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Oct 16 14:21:57 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Oct 2018 15:21:57 +0100 Subject: Using NIO2 for writing zip file entries without corresponding folder entries In-Reply-To: References: <9d401812-2704-7cb2-d57c-c8ea6efa32e7@oracle.com> Message-ID: <1cc3aeba-c47c-ac25-f67d-a96457eb2236@oracle.com> On 16/10/2018 14:00, Rafael Winterhalter wrote: > : > > ? ? ? ? // Emulate merging two zip files without directories using NIO2 > ? ? ? ? try ( > ? ? ? ? ? ? FileSystem source = FileSystems.newFileSystem(sample, null); > ? ? ? ? ? ? FileSystem target = FileSystems.newFileSystem(other, null) > ? ? ? ? ) { > ? ? ? ? ? ? Path path = source.getPath("foo/bar.txt"); > ? ? ? ? ? ? Files.copy(path, target.getPath(source.toString())); > ? ? ? ? } > > It surprised me that this does not work when trying to migrate from > ZipInputStream to NIO2. If I read this correctly, it is attempting to copy foo/bar.txt from one file system to a non-existent directory in the other file system. As I said, the zip file system tries to behave like a regular file system so it is correct to fail when the directory doesn't exist. I think the only thing we can do here is introduce a configuration option to strip directories when writing, it's just something that hasn't come up before. -Alan From rafael.wth at gmail.com Tue Oct 16 14:48:15 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Tue, 16 Oct 2018 16:48:15 +0200 Subject: Using NIO2 for writing zip file entries without corresponding folder entries In-Reply-To: <1cc3aeba-c47c-ac25-f67d-a96457eb2236@oracle.com> References: <9d401812-2704-7cb2-d57c-c8ea6efa32e7@oracle.com> <1cc3aeba-c47c-ac25-f67d-a96457eb2236@oracle.com> Message-ID: Yes, this would be an option and I understand that this is a corner-case but if it can be covered, great. Ideally, one could also choose to have only certain directories stripped for allowing to retain as much as possible of the original format. Thanks for considering this! Best regards, Rafael Am Di., 16. Okt. 2018 um 16:22 Uhr schrieb Alan Bateman < Alan.Bateman at oracle.com>: > On 16/10/2018 14:00, Rafael Winterhalter wrote: > > : > > > > // Emulate merging two zip files without directories using NIO2 > > try ( > > FileSystem source = FileSystems.newFileSystem(sample, null); > > FileSystem target = FileSystems.newFileSystem(other, null) > > ) { > > Path path = source.getPath("foo/bar.txt"); > > Files.copy(path, target.getPath(source.toString())); > > } > > > > It surprised me that this does not work when trying to migrate from > > ZipInputStream to NIO2. > If I read this correctly, it is attempting to copy foo/bar.txt from one > file system to a non-existent directory in the other file system. As I > said, the zip file system tries to behave like a regular file system so > it is correct to fail when the directory doesn't exist. I think the only > thing we can do here is introduce a configuration option to strip > directories when writing, it's just something that hasn't come up before. > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Oct 16 17:15:20 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Oct 2018 10:15:20 -0700 Subject: RFC: 5029431: (bf) Add absolute bulk put and get methods Message-ID: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> https://bugs.openjdk.java.net/browse/JDK-5029431 http://cr.openjdk.java.net/~bpb/5029431/webrev.00/ This is a request for comment before proceeding to the complete task (add more methods?, tune the specification, add tests, file CSR). In the linked patch, two methods are added to the $Type$Buffer classes: 1) absolute bulk get: $Type$Buffer get(int index, $type$[] dst, int offset, int length) 2) absolute bulk put: $Type$Buffer put(int index, $type$[] src, int offset, int length) Other similar methods proposed to be added are: 3) $Type$Buffer get(int index, $type$[] dst) 4) $Type$Buffer put(int index, $type$[] src) 5) $Type$Buffer put(int index, $Type$Buffer src, int offset, int length) Does this look like an appropriate set of methods overall? With respect to methods 1 and 2, a question I have concerns the exception(s) which may be thrown. In the patch, an IndexOutOfBoundsException is thrown if there is any inconsistency in the supplied parameters. This is analogous to the absolute get and put methods which handle a single value [1, 2], but is not very precise. One alternative would be instead to specify these exceptions for parameter consistency: * IllegalArgumentException if index < 0 * IndexOutOfBoundsException if {dst,src}.length, offset, and length do not meet the preconditions * Buffer{Under,Over}flowException for {get,put} if index + length > capacity() Here throwing an IAE is analogous to the behavior of alignmentOffset() [3], and the other two exceptions are as thrown by the analogous relative bulk get and put methods [4, 5]. One difficulty with using Buffer{Under,Over}flowException for this purpose is that these exceptions are documented as being specific to *relative* get and put operations [6, 7]. Using them in this case would require revising their specifications. Thanks, Brian [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#get(int) [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#put(int,byte) [3] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#alignmentOffset(int,int) [4] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#get(byte%5B%5D,int,int) [5] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#put(byte%5B%5D,int,int) [6] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/BufferUnderflowException.html [7] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/BufferOverflowException.html From Alan.Bateman at oracle.com Tue Oct 16 19:01:04 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Oct 2018 20:01:04 +0100 Subject: RFC: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> References: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> Message-ID: On 16/10/2018 18:15, Brian Burkhalter wrote: > : > > With respect to methods 1 and 2, a question I have concerns the exception(s) which may be thrown. In the patch, an IndexOutOfBoundsException is thrown if there is any inconsistency in the supplied parameters. This is analogous to the absolute get and put methods which handle a single value [1, 2], but is not very precise. One alternative would be instead to specify these exceptions for parameter consistency: > > * IllegalArgumentException if index < 0 > * IndexOutOfBoundsException if {dst,src}.length, offset, and length do not meet the preconditions > * Buffer{Under,Over}flowException for {get,put} if index + length > capacity() I don't have just now to go through in detail but just to say that the existing absolute methods throw IOOBE when index is negative. They also throw IOOBE when the index + #bytes is beyond the limit. So I think we should keep those consistent. Also , and you noted, Buffer{Under,Over}Exception are for the methods that get/put from the buffer position so I don't think you'll need them here. -Alan From brian.burkhalter at oracle.com Tue Oct 16 19:06:48 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Oct 2018 12:06:48 -0700 Subject: RFC: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> Message-ID: <040D00A0-21D6-48F0-9380-365BE768F8F8@oracle.com> > On Oct 16, 2018, at 12:01 PM, Alan Bateman wrote: > > On 16/10/2018 18:15, Brian Burkhalter wrote: >> : >> >> With respect to methods 1 and 2, a question I have concerns the exception(s) which may be thrown. In the patch, an IndexOutOfBoundsException is thrown if there is any inconsistency in the supplied parameters. This is analogous to the absolute get and put methods which handle a single value [1, 2], but is not very precise. One alternative would be instead to specify these exceptions for parameter consistency: >> >> * IllegalArgumentException if index < 0 >> * IndexOutOfBoundsException if {dst,src}.length, offset, and length do not meet the preconditions >> * Buffer{Under,Over}flowException for {get,put} if index + length > capacity() > I don't have time just now to go through in detail but just to say that the existing absolute methods throw IOOBE when index is negative. They also throw IOOBE when the index + #bytes is beyond the limit. So I think we should keep those consistent. Also , and you noted, Buffer{Under,Over}Exception are for the methods that get/put from the buffer position so I don't think you'll need them here. OK so it sounds like the existing patch is headed in the right direction at least. One thing I noticed in the non-direct relative bulk methods is that surprisingly System.arraycopy() is not used when hasArray() returns true. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Oct 16 19:14:26 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Oct 2018 20:14:26 +0100 Subject: RFC: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <040D00A0-21D6-48F0-9380-365BE768F8F8@oracle.com> References: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> <040D00A0-21D6-48F0-9380-365BE768F8F8@oracle.com> Message-ID: On 16/10/2018 20:06, Brian Burkhalter wrote: > > One thing I noticed in the non-direct relative bulk methods is that > surprisingly System.arraycopy() is not used when hasArray() returns true. > I checked HeapByteBuffer and it is generated to arraycopy in the relative bulk op but maybe you mean a different case? -Alan From brian.burkhalter at oracle.com Tue Oct 16 19:15:35 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Oct 2018 12:15:35 -0700 Subject: RFC: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: References: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> <040D00A0-21D6-48F0-9380-365BE768F8F8@oracle.com> Message-ID: > On Oct 16, 2018, at 12:14 PM, Alan Bateman wrote: > > On 16/10/2018 20:06, Brian Burkhalter wrote: >> >> One thing I noticed in the non-direct relative bulk methods is that surprisingly System.arraycopy() is not used when hasArray() returns true. >> > I checked HeapByteBuffer and it is generated to arraycopy in the relative bulk op but maybe you mean a different case? In X-Buffer.java.template. I did not look at HeapByteBuffer. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Tue Oct 16 21:01:13 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 16 Oct 2018 17:01:13 -0400 Subject: RFC: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> References: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> Message-ID: <71251e43-1a80-f156-2361-680ddb0c2582@oracle.com> Hi Brian, Looks like the right shape overall. I would agree that IOOBE is the right exception for all the parameter consistency checks. But with the different checks, the bare checkBounds method's IOOBE exception with no message will be very uninformative. Take a look the jdk.internal.util.Preconditions.checkFrom* methods. At least that would provide a consistent set of exception message formats and were designed to be inlined and efficient in the checks. The other options for 3), 4), and 5) is useful convenience methods. $.02, Roger On 10/16/2018 01:15 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-5029431 > http://cr.openjdk.java.net/~bpb/5029431/webrev.00/ > > This is a request for comment before proceeding to the complete task (add more methods?, tune the specification, add tests, file CSR). > > In the linked patch, two methods are added to the $Type$Buffer classes: > > 1) absolute bulk get: $Type$Buffer get(int index, $type$[] dst, int offset, int length) > 2) absolute bulk put: $Type$Buffer put(int index, $type$[] src, int offset, int length) > > Other similar methods proposed to be added are: > > 3) $Type$Buffer get(int index, $type$[] dst) > 4) $Type$Buffer put(int index, $type$[] src) > 5) $Type$Buffer put(int index, $Type$Buffer src, int offset, int length) > > Does this look like an appropriate set of methods overall? > > With respect to methods 1 and 2, a question I have concerns the exception(s) which may be thrown. In the patch, an IndexOutOfBoundsException is thrown if there is any inconsistency in the supplied parameters. This is analogous to the absolute get and put methods which handle a single value [1, 2], but is not very precise. One alternative would be instead to specify these exceptions for parameter consistency: > > * IllegalArgumentException if index < 0 > * IndexOutOfBoundsException if {dst,src}.length, offset, and length do not meet the preconditions > * Buffer{Under,Over}flowException for {get,put} if index + length > capacity() > > Here throwing an IAE is analogous to the behavior of alignmentOffset() [3], and the other two exceptions are as thrown by the analogous relative bulk get and put methods [4, 5]. One difficulty with using Buffer{Under,Over}flowException for this purpose is that these exceptions are documented as being specific to *relative* get and put operations [6, 7]. Using them in this case would require revising their specifications. > > Thanks, > > Brian > > [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#get(int) > [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#put(int,byte) > [3] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#alignmentOffset(int,int) > [4] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#get(byte%5B%5D,int,int) > [5] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html#put(byte%5B%5D,int,int) > [6] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/BufferUnderflowException.html > [7] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/BufferOverflowException.html -- Thanks, Roger From brian.burkhalter at oracle.com Tue Oct 16 21:33:45 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Oct 2018 14:33:45 -0700 Subject: RFC: 5029431: (bf) Add absolute bulk put and get methods In-Reply-To: <71251e43-1a80-f156-2361-680ddb0c2582@oracle.com> References: <22E71B4C-BB31-4DB1-8905-AD68D0346CB3@oracle.com> <71251e43-1a80-f156-2361-680ddb0c2582@oracle.com> Message-ID: <1B446429-A069-4392-A3C3-73EAFF4B9470@oracle.com> Hi Roger, > On Oct 16, 2018, at 2:01 PM, Roger Riggs wrote: > > Looks like the right shape overall. Good! > I would agree that IOOBE is the right exception for all the parameter consistency checks. > But with the different checks, the bare checkBounds method's IOOBE exception with > no message will be very uninformative. > > Take a look the jdk.internal.util.Preconditions.checkFrom* methods. > At least that would provide a consistent set of exception message formats > and were designed to be inlined and efficient in the checks. Will do. I think these are invoked by the Objects.checkFrom ? methods? > The other options for 3), 4), and 5) is useful convenience methods. Good. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.mckenna at oracle.com Fri Oct 19 13:25:08 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 19 Oct 2018 14:25:08 +0100 Subject: [11u] Request for Approval: Backport of 8209576: java.nio.file.Files.writeString writes garbled UTF-16 instead of UTF-8 In-Reply-To: <338a1cdf-a40f-412b-8c7f-fe0c8f7aec4c@default> References: <338a1cdf-a40f-412b-8c7f-fe0c8f7aec4c@default> Message-ID: <20181019132508.GB4921@vimes> Please follow the jdk-updates approval process: http://openjdk.java.net/projects/jdk-updates/approval.html -Rob On 18/10/18 11:18, Deepak Kejriwal wrote: > Hi, > > > > Please approve the backport of 8209576 to 11u. > > > > BugHYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8209576": https://bugs.openjdk.java.net/browse/JDK- 8209576 > > JDK Change set: http://hg.openjdk.java.net/jdk/jdk/rev/8dfed4387312 > > JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-August/054916.html > > > > Changes applied cleanly to jdk11u. > > All the related testing is done and is a pass (Mach5 Jobid: dkejriwa-jdk11u-20181018-1326-6846) > > > > Regards, > > Deepak > > From gnu.andrew at redhat.com Sat Oct 20 17:50:45 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 20 Oct 2018 18:50:45 +0100 Subject: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: References: <68f27940-c00c-70e3-43ae-caba5fd7b821@oracle.com> <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> Message-ID: On Tue, 22 May 2018 at 07:39, Alan Bateman wrote: > > On 21/05/2018 22:56, Ismael Juma wrote: > > Any thoughts on a backport to Java 8? Java 10 would be nice to have, > > but Java 11 is not far away and I don't expect many users to stick > > with Java 10 for long given the update policy. However, many users > > will stick to Java 8 for a long time and it would be good to restore > > the behaviour there. > > > I don't have cycles to get involved in changes for JDK 8 updates. > However, I agree JDK-8168628 should be backed out from jdk8u. > > -Alan Was there any action on this for 8u? 8168628 just went out in 8u191 (earlier inclusion is only listed for b30+ builds, which seem to refer to Oracle customer builds) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Sat Oct 20 18:08:56 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 20 Oct 2018 19:08:56 +0100 Subject: 8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space In-Reply-To: References: <68f27940-c00c-70e3-43ae-caba5fd7b821@oracle.com> <5c34a51a-d728-7671-bcbd-2b5e2766496b@oracle.com> Message-ID: On Sat, 20 Oct 2018 at 18:50, Andrew Hughes wrote: > > On Tue, 22 May 2018 at 07:39, Alan Bateman wrote: > > > > On 21/05/2018 22:56, Ismael Juma wrote: > > > Any thoughts on a backport to Java 8? Java 10 would be nice to have, > > > but Java 11 is not far away and I don't expect many users to stick > > > with Java 10 for long given the update policy. However, many users > > > will stick to Java 8 for a long time and it would be good to restore > > > the behaviour there. > > > > > I don't have cycles to get involved in changes for JDK 8 updates. > > However, I agree JDK-8168628 should be backed out from jdk8u. > > > > -Alan > > Was there any action on this for 8u? 8168628 just went out in 8u191 > (earlier inclusion is only listed for b30+ builds, which seem to refer > to Oracle customer builds) > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Web Site: http://fuseyism.com > Twitter: https://twitter.com/gnu_andrew_java > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Ah, I see https://bugs.openjdk.java.net/browse/JDK-8202261 is scheduled for 8u202 (got confused with 8202116 and it doesn't mention 8168628 in the changeset). I've flagged it with 8u-CPU-critical-request so it can hopefully get in 8u201 as well. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From christoph.langer at sap.com Fri Oct 26 15:12:45 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Oct 2018 15:12:45 +0000 Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions Message-ID: Hi, please review this enhancement of jdk.nio.zipfs to support Posix file permissions. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 I had already posted this change as part of a larger fix for "6194856: Zip Files lose ALL ownership and permissions of the files" [1]. With the original proposal I was also addressing the java.util.zip API and the jar tool. However, I've decided to split this endeavor into 2 parts. While I still want to follow up on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in first. Both places don't have dependencies to each other and since zipfs does not change an external API, I guess the bar here is lower. Maybe it is even a candidate for down-porting to jdk11u in the future. After my fix, zipfs will support the PosixFileAttributeView. Posix file attributes can't be fully supported since owner and group are not handled in zip files. So methods supposed to get these attributes will return an UnsupportedOperationException. But the posix permissions will now be correctly handled, that is stored into and read from the zip file. @Sherman: Following suggestions from your review, I removed the test with the binary zip file. I initially thought it is a good idea to test on a well-known file. However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip file and reading it again so I guess test coverage is quite complete here. Furthermore, I made some public declarations in ZipUtils package private which should suffice. I also tried to address your performance concerns with permsToFlags and permsFromFlags. In permsToFlags I will now simply iterate to the set of permissions and add the flags to the return value. It's probably more performant than the streaming approach and doesn't look much worse in the code. In permsFromFlags I added a cache of permission sets which should avoid constant calls to the streaming. However, as the return value needs to be mutable, I have to clone the cached permissions. Maybe it would have the same or even better performance if we iteratively fill a new set of permissions each time permsToFlags gets called. What do you think? Do we need a CSR for this patch? Thanks & Best regards Christoph [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055971.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Oct 26 19:01:35 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 26 Oct 2018 12:01:35 -0700 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD153B4C7@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD153B4C7@ORSMSX113.amr.corp.intel.com> Message-ID: Hi Lucy, For now, just a few minor points regarding the API verbiage. 1. jdk.net .Sockets 474: I think ?server-socket? should have the hyphen removed: ?server socket?. 2. jdk.net .RdmaSocketOptions 67, 80, 93: Should it say ?bound or connected? instead of simply ?bound?? 69, 82, 95: ?RDMA based -> ?RDMA-based? (add a hyphen) 69, 82, 95: I don?t think that RdmaSocketImpl should be mentioned in the javadoc as it is not in the public API. Thanks, Brian > On Oct 5, 2018, at 8:23 PM, Lu, Yingqi wrote: > > The link http://cr.openjdk.java.net/~ylu/8195160.14/ is updated with the additional file jdk.internal.misc.JdkRdmaSocketImplAccess.java. It might be just me, but I needed to refresh both pages http://cr.openjdk.java.net/~ylu/8195160.14/ andhttp://cr.openjdk.java.net/~ylu/8195160.14/jdk12-8195160-version14.patch to get the updated content. > > Please let me know if you see any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yingqi.lu at intel.com Fri Oct 26 20:19:21 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 26 Oct 2018 20:19:21 +0000 Subject: adding rsockets support into JDK In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AD153B4C7@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1556D05@ORSMSX113.amr.corp.intel.com> Hi Brian, Thank you very much for the help reviewing the APIs. I already made the changes accordingly. Have you got any chance to look at the test cases? I plan to wait for your feedback there and send out the webrev version 15 with all the changes. Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Friday, October 26, 2018 12:02 PM To: Lu, Yingqi Cc: Aundhe, Shirish ; nio-dev at openjdk.java.net; Viswanathan, Sandhya ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, For now, just a few minor points regarding the API verbiage. 1. jdk.net.Sockets 474: I think ?server-socket? should have the hyphen removed: ?server socket?. 2. jdk.net.RdmaSocketOptions 67, 80, 93: Should it say ?bound or connected? instead of simply ?bound?? 69, 82, 95: ?RDMA based -> ?RDMA-based? (add a hyphen) 69, 82, 95: I don?t think that RdmaSocketImpl should be mentioned in the javadoc as it is not in the public API. Thanks, Brian On Oct 5, 2018, at 8:23 PM, Lu, Yingqi > wrote: The link http://cr.openjdk.java.net/~ylu/8195160.14/ is updated with the additional file jdk.internal.misc.JdkRdmaSocketImplAccess.java. It might be just me, but I needed to refresh both pages http://cr.openjdk.java.net/~ylu/8195160.14/ andhttp://cr.openjdk.java.net/~ylu/8195160.14/jdk12-8195160-version14.patch to get the updated content. Please let me know if you see any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Oct 26 20:25:22 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 26 Oct 2018 13:25:22 -0700 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1556D05@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD153B4C7@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1556D05@ORSMSX113.amr.corp.intel.com> Message-ID: Hi Lucy, > On Oct 26, 2018, at 1:19 PM, Lu, Yingqi wrote: > > Thank you very much for the help reviewing the APIs. I already made the changes accordingly. You?re welcome. > Have you got any chance to look at the test cases? I plan to wait for your feedback there and send out the webrev version 15 with all the changes. Not yet. Rather than to wait for further review, it might not hurt to either update version 14 in place or publish version 15 with the foregoing API verbiage changes as this will permit the CSR to be updated. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Oct 26 20:39:00 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Oct 2018 20:39:00 +0000 Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions In-Reply-To: References: Message-ID: <0a484475700d445d889992f229e4a689@sap.com> Hi Andrew, you might have a point here. I'll revisit that. Thanks Christoph > -----Original Message----- > From: Andrew Luo > Sent: Freitag, 26. Oktober 2018 20:43 > To: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; nio-dev ; Xueming > Shen > Cc: Schmelter, Ralf > Subject: RE: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File > Permissions > > I'm not a committer/reviewer but noticed something: > > In ZipUtils.java: > > private static final Map> permCache = > new WeakHashMap<>(); > > This is static, and is concurrently modified, so will it cause issues if multiple > threads are operating on ZIP filesystems (even if they are different > objects/ZIP files)? > > Thanks, > > -Andrew > > -----Original Message----- > From: core-libs-dev On Behalf > Of Langer, Christoph > Sent: Friday, October 26, 2018 8:13 AM > To: core-libs-dev ; nio-dev dev at openjdk.java.net>; Xueming Shen > Cc: Schmelter, Ralf > Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions > > Hi, > > please review this enhancement of jdk.nio.zipfs to support Posix file > permissions. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 > > I had already posted this change as part of a larger fix for "6194856: Zip Files > lose ALL ownership and permissions of the files" [1]. With the original > proposal I was also addressing the java.util.zip API and the jar tool. However, > I've decided to split this endeavor into 2 parts. While I still want to follow up > on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in first. > Both places don't have dependencies to each other and since zipfs does not > change an external API, I guess the bar here is lower. Maybe it is even a > candidate for down-porting to jdk11u in the future. > > After my fix, zipfs will support the PosixFileAttributeView. Posix file > attributes can't be fully supported since owner and group are not handled in > zip files. So methods supposed to get these attributes will return an > UnsupportedOperationException. But the posix permissions will now be > correctly handled, that is stored into and read from the zip file. > > @Sherman: > Following suggestions from your review, I removed the test with the binary > zip file. I initially thought it is a good idea to test on a well-known file. > However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip > file and reading it again so I guess test coverage is quite complete here. > Furthermore, I made some public declarations in ZipUtils package private > which should suffice. > I also tried to address your performance concerns with permsToFlags and > permsFromFlags. In permsToFlags I will now simply iterate to the set of > permissions and add the flags to the return value. It's probably more > performant than the streaming approach and doesn't look much worse in the > code. In permsFromFlags I added a cache of permission sets which should > avoid constant calls to the streaming. However, as the return value needs to > be mutable, I have to clone the cached permissions. Maybe it would have > the same or even better performance if we iteratively fill a new set of > permissions each time permsToFlags gets called. What do you think? > > Do we need a CSR for this patch? > > Thanks & Best regards > Christoph > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018- > October/055971.html From yingqi.lu at intel.com Fri Oct 26 21:48:46 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 26 Oct 2018 21:48:46 +0000 Subject: adding rsockets support into JDK In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AD153B4C7@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1556D05@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1556EB6@ORSMSX113.amr.corp.intel.com> Hi Brian, Here is the version 15 of the patch: http://cr.openjdk.java.net/~ylu/8195160.15 It has your feedback incorporated. Thanks, Lucy From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Friday, October 26, 2018 1:25 PM To: Lu, Yingqi Cc: Aundhe, Shirish ; nio-dev at openjdk.java.net; Viswanathan, Sandhya ; Kaczmarek, Eric Subject: Re: adding rsockets support into JDK Hi Lucy, On Oct 26, 2018, at 1:19 PM, Lu, Yingqi > wrote: Thank you very much for the help reviewing the APIs. I already made the changes accordingly. You?re welcome. Have you got any chance to look at the test cases? I plan to wait for your feedback there and send out the webrev version 15 with all the changes. Not yet. Rather than to wait for further review, it might not hurt to either update version 14 in place or publish version 15 with the foregoing API verbiage changes as this will permit the CSR to be updated. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sun Oct 28 09:09:54 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Oct 2018 09:09:54 +0000 Subject: adding rsockets support into JDK In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1556EB6@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD153B4C7@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1556D05@ORSMSX113.amr.corp.intel.com> <9ACD5B67AAC5594CB6268234CF29CF9AD1556EB6@ORSMSX113.amr.corp.intel.com> Message-ID: <18649597-01aa-0b59-448f-47328d048d4c@oracle.com> On 26/10/2018 22:48, Lu, Yingqi wrote: > > Hi Brian, > > Here is the version 15 of the patch: > http://cr.openjdk.java.net/~ylu/8195160.15 > > > I went through the current patch. One thing that isn't quite right is that Socket/ServerSocket have been updated so that the supportedOptions API returns the RDMA options. This is something that been pushed down to the implementation of the SocketImpl. When supportedOptions is invoked it will delegate to the socket impl and that should add the RDMA socket options. I also see that SocketImpl setSocket/setServerSocket have been updated to special case the RDMA SocketImp. This shouldn't be needed so I think we need to understand the setSocket/setServerSocket usage to see how this can be restructured. If we can fix that then the RDMA SocketImpl should be just an implementation and the need for the shared secrets mechanism should go away. sun.net.ch.Net defines static methods, it should be final. RdmaNet work the same way, it doesn't need to extend Net. The RdmaSocketOptions API mostly looks okay. The only thing that seems to be missed is some hints as to the valid ranges for the RMDA send/receive queue size. Does setOption(RMDA_RQSIZE, 0) or setOption(RMDA_RQSIZE, -1) make sense for example. It's okay to specify the upper limit as implementation specific, it's the 0 and negative values that aren't clear. In RdmaSocketOptions class description then I assume "The rsocket implementaiton is Linux only" can be dropped or converted to an API note. One implementation nit is that it looks like loadRdmaFuncs will be called multiple times. I assume this should have a guard so that it only executes once. We touched on IPv6 addresses in some of the early discussions here - can you summarize what the support is? That's all I have for now. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Oct 29 09:26:56 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Oct 2018 09:26:56 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) Message-ID: <5030914b571a449bba7a98152fdc0850@sap.com> Hi, here's an update of my webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.1/ I added synchronization to the updating of permCache in ZipUtils.java to avoid concurrent modifications. As per request from Alan, I'm adding security-dev to get a review from security perspective. Thanks Christoph From: Langer, Christoph Sent: Freitag, 26. Oktober 2018 17:13 To: core-libs-dev ; nio-dev ; 'Xueming Shen' Cc: Schmelter, Ralf ; 'Volker Simonis' Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions Hi, please review this enhancement of jdk.nio.zipfs to support Posix file permissions. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 I had already posted this change as part of a larger fix for "6194856: Zip Files lose ALL ownership and permissions of the files" [1]. With the original proposal I was also addressing the java.util.zip API and the jar tool. However, I've decided to split this endeavor into 2 parts. While I still want to follow up on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in first. Both places don't have dependencies to each other and since zipfs does not change an external API, I guess the bar here is lower. Maybe it is even a candidate for down-porting to jdk11u in the future. After my fix, zipfs will support the PosixFileAttributeView. Posix file attributes can't be fully supported since owner and group are not handled in zip files. So methods supposed to get these attributes will return an UnsupportedOperationException. But the posix permissions will now be correctly handled, that is stored into and read from the zip file. @Sherman: Following suggestions from your review, I removed the test with the binary zip file. I initially thought it is a good idea to test on a well-known file. However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip file and reading it again so I guess test coverage is quite complete here. Furthermore, I made some public declarations in ZipUtils package private which should suffice. I also tried to address your performance concerns with permsToFlags and permsFromFlags. In permsToFlags I will now simply iterate to the set of permissions and add the flags to the return value. It's probably more performant than the streaming approach and doesn't look much worse in the code. In permsFromFlags I added a cache of permission sets which should avoid constant calls to the streaming. However, as the return value needs to be mutable, I have to clone the cached permissions. Maybe it would have the same or even better performance if we iteratively fill a new set of permissions each time permsToFlags gets called. What do you think? Do we need a CSR for this patch? Thanks & Best regards Christoph [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055971.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Oct 29 12:06:00 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Oct 2018 12:06:00 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) In-Reply-To: <5030914b571a449bba7a98152fdc0850@sap.com> References: <5030914b571a449bba7a98152fdc0850@sap.com> Message-ID: On 29/10/2018 09:26, Langer, Christoph wrote: > : > > As per request from Alan, I?m adding security-dev to get a review from > security perspective. > > For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Oct 29 14:55:20 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Oct 2018 14:55:20 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) In-Reply-To: References: <5030914b571a449bba7a98152fdc0850@sap.com> Message-ID: <85c85aadb98b4b82a9ec0a6ee9cb8fa7@sap.com> Hi Alan, security guys, I've proposed a CSR for this change now: https://bugs.openjdk.java.net/browse/JDK-8213082. I also updated the webrev, simplifying jdk.nio.zipfs.ZipUtils.permsFromFlags and eliminating the WeakHashMap: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Since I've decoupled the changes to java.util.zip and jartool from those in jdk.zipfs, we're discussing only jdk.zipfs here. The implication of my change is that when working with files backed by the nio FileSystemProvider (java.nio.file.spi.FileSystemProvider) named "jar", which is the alias for zipfs, the files will support attributes of type java.nio.file.attribute.PosixFilePermissions ("posix:permissions"). It basically means that some methods of java.nio.file.Files that would return null or UnsupportedOperationException before would find an implementation now. Examples: https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getPosixFilePermissions(java.nio.file.Path,java.nio.file.LinkOption...) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#setPosixFilePermissions(java.nio.file.Path,java.util.Set) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#readAttributes(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributes.html https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getFileAttributeView(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributeView.html Thanks in advance for reviewing. Best regards Christoph From: Alan Bateman Sent: Montag, 29. Oktober 2018 13:06 To: Langer, Christoph ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen Cc: Volker Simonis ; Andrew Luo ; nio-dev Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) On 29/10/2018 09:26, Langer, Christoph wrote: : As per request from Alan, I'm adding security-dev to get a review from security perspective. For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: