Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

On 7/10/19 5:17 PM, Brian Burkhalter wrote: I incorporated Peter’s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method. The updated version is here: http://cr.openjdk

Re: RFR [14/java.xml] 8178843: A bug in an inner loop in MethodGenerator's getLocals method

+1 > On Jul 10, 2019, at 7:57 PM, Joe Wang wrote: > > Please review a cleanup that removes unused code. This code has two errors, > one as indicated in the bug report, another attempting to loop through > allVarsEverDeclared that was just created (meaning size=0). It just ensures > again that

Re: EnumSet.class serialization broken - twice - JDK-8227368

On 7/10/19 9:54 AM, Peter Levart wrote: On 7/10/19 6:03 PM, Joe Darcy wrote: Hello, I'd advise against including at least part of the comment     // declare serialization compatibility with JDK 8 (see JDK-8227368) We generally don't include bug numbers in the text of the code and rely map

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

I incorporated Peter’s version, adding the security check in cancelDeleteOnExit(), tweaking its verbiage along with that of deleteOnExit(), and modified the test DeleteOnExit to verify the new method. The updated version is here: http://cr.openjdk.java.net/~bpb/8193072/webrev.03/

RFR [14/java.xml] 8178843: A bug in an inner loop in MethodGenerator's getLocals method

Please review a cleanup that removes unused code. This code has two errors, one as indicated in the bug report, another attempting to loop through allVarsEverDeclared that was just created (meaning size=0). It just ensures again that the code was never used. JBS: https://bugs.openjdk.java.net/

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Peter / Sean, Thanks for the comments. > On Jul 10, 2019, at 5:36 AM, Peter Levart wrote: > > There are various interleavings of threads that could cause the file to be > left undeleted when VM exits. > > To cover concurrent scenarios such as above, the code could use reference > counting. L

Re: EnumSet.class serialization broken - twice - JDK-8227368

On 7/10/19 6:03 PM, Joe Darcy wrote: Hello, I'd advise against including at least part of the comment     // declare serialization compatibility with JDK 8 (see JDK-8227368) We generally don't include bug numbers in the text of the code and rely mapping from the SCM to the bug database to pro

Re: [14]RFR of JDK-8227289:Enable assertions for some shell to java conversion tests after JDK-8218960

Looks good to me. Naoto On 7/9/19 11:53 PM, Ying Zhou wrote: Hello, Please review this patch for updating below tests by adding -ea/esa to launcher parameters. - /test/jdk/java/util/Calendar/SupplementalJapaneseEraTestRun.java - /test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheckRun.ja

Re: EnumSet.class serialization broken - twice - JDK-8227368

Hello, I'd advise against including at least part of the comment     // declare serialization compatibility with JDK 8 (see JDK-8227368) We generally don't include bug numbers in the text of the code and rely mapping from the SCM to the bug database to provide the (sometimes large!) additiona

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

On 7/9/19 7:40 PM, Brian Burkhalter wrote: I don’t know. On the one hand this does not take an action like reading, writing, or deleting, but on the other it could end up causing files to be left lying around after VM termination which were expected to be deleted. I suppose that could be consi

Re: 8193072: File.delete() should remove its path from DeleteOnExitHook.files

Hi, On 7/9/19 8:08 PM, Brian Burkhalter wrote: On Jul 9, 2019, at 8:31 AM, Brian Burkhalter wrote: Since deleteOnExit() is an deliberate act, perhaps there should be a corresponding withdrawDeleteOnExit() that reverses it so that it is intentional and not a side-effect of other File method

Re: EnumSet.class serialization broken - twice - JDK-8227368

Hi Stuart, On 7/10/19 4:32 AM, Stuart Marks wrote: 1. New changeset with constant version of EnumSet.serialVersionUID. This is already in the webrev.01 changeset. webrev.02 is an attempt to sneak the change without being visible in the serialized-form.html. Ah. I skipped webrev.01 because I