Re: ZipFileSystem and the impact of JDK-8031748 on ordering of MANIFEST files in the created jars

Hello Lance, On 14/11/19 9:35 PM, Lance Andersen wrote: > ... > > There is an existing Zip FS enhancement > request, https://bugs.openjdk.java.net/browse/JDK-8211917.  Thank you, I hadn't noticed this one before sending this mail. I'll keep a watch on this one. -Jaikiran

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 11/14/19 5:04 PM, David Holmes wrote: Hi Mandy, On 15/11/2019 10:51 am, Mandy Chung wrote: On 11/14/19 8:04 AM, Mandy Chung wrote: On 11/14/19 2:33 AM, Alan Bateman wrote: On 14/11/2019 04:57, Mandy Chung wrote: Updated in place:

Re: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi Christoph, Thank you for looking into this. Overall, I think this is OK. Not sure there is currently any downside to removing the JAR FS right now outside of keeping the multi-release code separate. I would suggesting moving the code added to the constructor for checking the

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

Hi Mandy, On 15/11/2019 10:51 am, Mandy Chung wrote: On 11/14/19 8:04 AM, Mandy Chung wrote: On 11/14/19 2:33 AM, Alan Bateman wrote: On 14/11/2019 04:57, Mandy Chung wrote: Updated in place: http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 11/14/19 8:04 AM, Mandy Chung wrote: On 11/14/19 2:33 AM, Alan Bateman wrote: On 14/11/2019 04:57, Mandy Chung wrote: Updated in place: http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/ http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/ The addition of

Re: RFR 8233272 : The Class.forName specification should be updated to match the long-standing implementation with respect to class linking

On 11/14/19 4:42 PM, David Holmes wrote: On 15/11/2019 10:33 am, Brent Christian wrote: On 11/14/19 4:12 PM, David Holmes wrote: On 15/11/2019 9:58 am, Brent Christian wrote: http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/ Test is fine. Just one note/clarification:   63

Re: RFR 8233272 : The Class.forName specification should be updated to match the long-standing implementation with respect to class linking

On 15/11/2019 10:33 am, Brent Christian wrote: On 11/14/19 4:12 PM, David Holmes wrote: On 15/11/2019 9:58 am, Brent Christian wrote: http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/ Test is fine. Just one note/clarification:   63 // Loading (but not linking) Container will

Re: RFR 8233272 : The Class.forName specification should be updated to match the long-standing implementation with respect to class linking

On 11/14/19 4:12 PM, David Holmes wrote: On 15/11/2019 9:58 am, Brent Christian wrote: http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/ Test is fine. Just one note/clarification:  63 // Loading (but not linking) Container will succeed. Container was already loaded as part

Re: RFR 8233272 : The Class.forName specification should be updated to match the long-standing implementation with respect to class linking

Hi Brent, On 15/11/2019 9:58 am, Brent Christian wrote: On 11/14/19 8:22 AM, Mandy Chung wrote: On 11/13/19 10:37 AM, Brent Christian wrote: The spec change looks fine. OK, thanks. +1 from me on spec changes. As for the test, I expect that it simply calls Class.forName("Provider",

Re: [ping] 8179320: File.getUsableSpace() returns a negative number on very large file system

Hi Roger, > On Nov 14, 2019, at 1:35 PM, Roger Riggs wrote: > > The changes look fine. Thanks for the comments. > In the CSR, the typography of the code font for |java.io.File.getXSpace > |will not read well in all the places where the summary sentence is used by > itself. > Spelling out the

Re: RFR 8233272 : The Class.forName specification should be updated to match the long-standing implementation with respect to class linking

On 11/14/19 8:22 AM, Mandy Chung wrote: On 11/13/19 10:37 AM, Brent Christian wrote: The spec change looks fine. OK, thanks. As for the test, I expect that it simply calls Class.forName("Provider", false, ucl) and then should succeed. Then calling Class.forName("Provider", true, ucl)

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

On 15/11/2019 1:13 am, gerard ziemski wrote: Thank you for the review. I'm definitively going to wait for Christoph to check in his fix first. I tried in fact to leave jdk_util.c/.h files in empty without removing them from the repo, and even though Mac/Linux were OK with that,

Re: [ping] 8179320: File.getUsableSpace() returns a negative number on very large file system

Hi Brian, The changes look fine. In the CSR, the typography of the code font for |java.io.File.getXSpace |will not read well in all the places where the summary sentence is used by itself. Spelling out the names of the affected methods will help. Having to unpack a zip file to see the

Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

Hi Volker, > On Nov 14, 2019, at 12:05 PM, Volker Simonis wrote: > > On 14.11.19 17:38, Lance Andersen wrote: >>> On Nov 14, 2019, at 11:27 AM, Volker Simonis >> > wrote: >>> >>> I am not sure throwing a SkippedException is correct, I would probably

Should Java support ERROR_NO_MORE_FILES when canonicalizing paths on Windows?

Hi all, while the details can be read on SO[1][2], the bottom line is that I have a setup in which Windows sets the error code ERROR_NO_MORE_FILES during calls to FindFirstFileW sometimes. In theory that shouldn't happen, but it simply does once in a while and make my Java daemon run into

Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

On 13.11.19 18:54, Lance Andersen wrote: Hi Volker, Thank you for doing this. As Christoph mentioned,  you can just do Path.of() and create the file in the work directory for the test. Done. If possible, I would use TestNG as that is consistent with the vast majority of the tests. I

Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

On 14.11.19 17:38, Lance Andersen wrote: On Nov 14, 2019, at 11:27 AM, Volker Simonis > wrote: On 14.11.19 16:27, Lance Andersen wrote: Hi Volker, On Nov 14, 2019, at 8:53 AM, Volker Simonis > wrote: On

Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

On 14.11.19 16:27, Lance Andersen wrote: Hi Volker, On Nov 14, 2019, at 8:53 AM, Volker Simonis > wrote: On 13.11.19 18:54, Lance Andersen wrote: Hi Volker, Thank you for doing this. As Christoph mentioned,  you can just do Path.of() and create the file in the

Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

On 13.11.19 17:26, Langer, Christoph wrote: Hi Volker, good catch in ZipFileSystem  The fix is the right thing to do. Hi Christoph, thanks for looking at my fix. I've prepared a new webrev at: http://cr.openjdk.java.net/~simonis/webrevs/2019/8234011.v1/ Please find my further comments

RE: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

Hi Volker, funny, I didn’t get aware of your mails until I now recognized that my mail client moved your mail into the “Amazon-advertisement-spam” folder of my mailbox.  I have to check and modify my filter rules… Ok, let’s continue the little bike-shed about the test then. First, thanks for

Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

> On Nov 14, 2019, at 11:27 AM, Volker Simonis wrote: > > On 14.11.19 16:27, Lance Andersen wrote: >> Hi Volker, >>> On Nov 14, 2019, at 8:53 AM, Volker Simonis >> >> >> wrote: >>> >>> On 13.11.19 18:54,

Re: RFR 8233272 : The Class.forName specification should be updated to match the long-standing implementation with respect to class linking

On 11/13/19 10:37 AM, Brent Christian wrote: Hi, Recently, the 2-arg and 3-arg Class.forName() methods were updated[1] to perform class linking, per the specification. However this change had to be reverted[2]. Instead, let's clarify the Class.forName() spec not to guarantee linking

Re: ZipFileSystem and the impact of JDK-8031748 on ordering of MANIFEST files in the created jars

Hi Jaikarian, This issue has been looked at several times over the years (see https://bugs.openjdk.java.net/browse/JDK-5046178 as an example) WRT JarInpuStream/MANIFEST There is an existing Zip FS enhancement request,

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 11/14/19 2:33 AM, Alan Bateman wrote: On 14/11/2019 04:57, Mandy Chung wrote: Updated in place: http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/ http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/ The addition of hasFullPrivilegeAccess looks okay and probably the

[ping] 8179320: File.getUsableSpace() returns a negative number on very large file system

> Begin forwarded message: > > From: Brian Burkhalter > Subject: 8179320: File.getUsableSpace() returns a negative number on very > large file system > Date: November 1, 2019 at 5:13:28 PM PDT > To: Core-Libs-Dev > > For this issue [1], please review this patch [2] and the corresponding

Re: ZipFileSystem and the impact of JDK-8031748 on ordering of MANIFEST files in the created jars

Adding core-libs-dev, since this also involves java.util.jar APIs. -Jaikiran On 14/11/19 8:47 PM, Jaikiran Pai wrote: > Please consider the code listed at the end of this mail. What it does is > uses ZipFileSystem to create 2 jar files with identical content. foo.jar > and bar.jar. Both these

RFR: 8234185: Cleanup usage of canonicalize function between libjava, hotspot and libinstrument

Hi, please review this cleanup change regarding function "canonicalize" of libjava. Bug: https://bugs.openjdk.java.net/browse/JDK-8234185 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234185.0/ The goal is to cleanup how this function is defined and used. One thing is, that there was

Re: RFR 8233187: Return Empty List if 0 Copies Requested in Collections nCopies

Hi Kiran, pleased to meet you Code like this should be written so that the common case has only one boolean test. On Thu, Nov 14, 2019 at 1:50 AM Kiran Ravikumar < kiran.sidhartha.raviku...@oracle.com> wrote: > Hi Guys, > > > Please review the following optimization to nCopies method to return

Re: RFR(XS): 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()

Hi Volker, > On Nov 14, 2019, at 8:53 AM, Volker Simonis wrote: > > On 13.11.19 18:54, Lance Andersen wrote: >> Hi Volker, >> Thank you for doing this. >> As Christoph mentioned, you can just do Path.of() and create the file in >> the work directory for the test. > > Done. > >> If possible,

RE: RFR: 8234089: (zipfs) Remove classes JarFileSystemProvider and JarFileSystem

Hi, after exchanging some direct mails with Lance, I came to the conclusion that the current behavior to ignore file system property "multi-release" when "releaseVersion" is explicitly set to null is the right thing to do. So I updated the webrev to reinstate this functionality and added

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

Thank you for the review. I'm definitively going to wait for Christoph to check in his fix first. I tried in fact to leave jdk_util.c/.h files in empty without removing them from the repo, and even though Mac/Linux were OK with that, Solaris/Windows were not. cheers On 11/13/19 9:21 PM,

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

Thank you for the review. I'm happy to wait for your fix to go in first - this will make my fix smaller. cheers On 11/13/19 2:05 PM, Langer, Christoph wrote: Hi Gerard, generally it looks like a nice cleanup. I've got a patch prepared though, which I was planning on posting tomorrow. It

Re: RFR (M) 8223261 "JDK-8189208 followup - remove JDK_GetVersionInfo0 and the supporting code"

Thank you for the review, will remove the comment and updated the webrev, but only after Christop Langer gets his fix in - I'm going to wait for him to check in first. cheers On 11/13/19 1:29 PM, Mandy Chung wrote: On 11/13/19 10:50 AM, gerard ziemski wrote: Hi all, Please review this

Re: RFR JDK-8233527: Update Lookup::hasPrivateAccess and Lookup::defineClass spec w.r.t. full power lookup

On 14/11/2019 04:57, Mandy Chung wrote: Updated in place: http://cr.openjdk.java.net/~mchung/jdk14/8233527/webrev.02/ http://cr.openjdk.java.net/~mchung/jdk14/8233527/specdiff/ The addition of hasFullPrivilegeAccess looks okay and probably the right thing to do. For the @deprecated message

RFR 8233187: Return Empty List if 0 Copies Requested in Collections nCopies

Hi Guys, Please review the following optimization to nCopies method to return empty list and to avoid instantiating an empty CopiesList object. JBS link : https://bugs.openjdk.java.net/browse/JDK-8233187 Patch: diff -r f279d8a9bb78 src/java.base/share/classes/java/util/Collections.java