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

On 7/9/19 1:57 AM, Stuart Marks wrote: 2. Create draft CSR. Created: https://bugs.openjdk.java.net/browse/JDK-8227432 Regards, Peter

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

Hi Stuart, On 7/9/19 1:57 AM, Stuart Marks wrote: Hi Peter, Thanks for picking this up, for filing the bug (JDK-8227368), and developing the fix. For the current release, I think we should go ahead and put in the "right" fix, that is, to define serialVersionUID the conventional way -- as

RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Can I please get a review and a sponsor for the patch that implements the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8225763 ? There has been a recent discussion about this change in the core-libs-dev mailing list here[1]. The latest version of the patch for this change is now

Re: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable

Hello Lance, On 08/07/19 11:16 PM, Lance Andersen wrote: > Hi Jaikiran, > > Thank you for your efforts here. > >> On Jul 6, 2019, at 9:59 AM, Jaikiran Pai > > wrote: >> >>> >>>  - Idempotency >>> >>> Yes, it looks to me like Inflater.end() and Deflater.end() >>>

Re: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13

+1 On 7/9/19 9:07 AM, naoto.s...@oracle.com wrote: Looks good, Ramanand. Naoto On 7/9/19 5:09 AM, Ramanand Patil wrote: Hi Naoto, Thank you for the review. Revised webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.02/ I plan to push the changes tomorrow, if there are no further

Re: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

Hi Thejasvi, Looks good, thanks for the updates Roger On 7/9/19 3:50 AM, Thejasvi Voniadka wrote: Hi Roger, Please find the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.4/ I have updated both lines 3924 and 3874 of

Re: [13] RFR: 8227127: Era designator not displayed correctly using the COMPAT provider

Hi Naoto, Looks fine. Thanks, Roger On 7/8/19 6:11 PM, naoto.s...@oracle.com wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8227127 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8227127/webrev.00/ This is a

RE: RFR: 8154520: java.time: appendLocalizedOffset() should return the localized "GMT" string

Hi Roger, Please find the updated webrev: http://cr.openjdk.java.net/~vagarwal/8154520/webrev.4/ I have updated both lines 3924 and 3874 of .../java/time/format/DateTimeFormatterBuilder.java. I have reduced the number of tests to just 3, and the number of locales to just 1 in

Re: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13

Looks good, Ramanand. Naoto On 7/9/19 5:09 AM, Ramanand Patil wrote: Hi Naoto, Thank you for the review. Revised webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.02/ I plan to push the changes tomorrow, if there are no further comments. Regards, Ramanand. -Original

RE: RFR: 8224560: (tz) Upgrade time-zone data to tzdata2019a and 8225580: tzdata2018i integration causes test failures on jdk-13

Hi Naoto, Thank you for the review. Revised webrev: http://cr.openjdk.java.net/~rpatil/8224560/webrev.02/ I plan to push the changes tomorrow, if there are no further comments. Regards, Ramanand. > -Original Message- > From: Naoto Sato > Sent: Monday, July 8, 2019 11:19 PM > To:

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

Hi Roger, You might be correct but I wrote up a different version at the end of yesterday. Not sure it is right but I might as well post it: http://cr.openjdk.java.net/~bpb/8193072/webrev.01/ Thanks, Brian > On Jul 9, 2019, at 7:34 AM, Roger Riggs wrote: > > The sequence described is the

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

Hi Brian, The sequence described is the specified behavior of the API, whether it is a developer mistake or not is unknowable but it would be a compatibility issue to change it. The filename is the key and there is no way to determine if it is the original file or a replacement. deleteOnExit

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

On Tue, Jul 9, 2019 at 8:19 AM Jaikiran Pai wrote: > - In addition, I have sneaked in an unrelated change in this patch, into > the Deflater.end() method: > > public void end() { > synchronized (zsRef) { > +// check if already closed > +if (zsRef.address() ==

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

Hi Brian, The interesting part will be writing/updating the specification to make it clear what happens and under what conditions. How often are File instances re-used vs creating new ones. And any interactions with other APIs that create or delete files with the same name.  (file channels,

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

Hi Roger, > On Jul 9, 2019, at 8:25 AM, Roger Riggs wrote: > > The interesting part will be writing/updating the specification to make it > clear what happens and under what conditions. > How often are File instances re-used vs creating new ones. > And any interactions with other APIs that

Re: The final optimized version of Dual-Pivot Quicksort (ver.19.1)

Hi, Is the webrev incomplete? It only contains the changes for DualPivotQuicksort.java, and not for Arrays.java, etc. Thanks, -Brent On 6/18/19 2:37 PM, Vladimir Yaroslavskiy wrote: Hi team, Please review the final optimized version of Dual-Pivot Quicksort (ver.19.1), see

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

> 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 methods. > > I think this is a better

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Hi Jaikiran, Again, thank you for your efforts here. Is there a CSR for this yet? This will need to approved prior to moving forward with committing the feature. I can sponsor once everything has been approved and finalized. ——— @implSpec This method is a no-op if this compressor has

Re: RFR [14] JDK-8225763 Inflater and Deflater should implement AutoCloseable

Hello Lance, On 10/07/19 2:25 AM, Lance Andersen wrote: > Hi Jaikiran, > > Again, thank you for your efforts here. > > Is there a CSR for this yet?  There isn't one yet. I will need help on this part, since I haven't created a CSR before. Is this something that I can create (I'm just a "author"

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

Brian, Just a note, one issue I see with webrev.01 is that JDK-7092892 is not resolved. On one hand more calls to DeleteOnExitHook should trigger class init sooner avoiding the issue. On the other it seems this could be more methods that could fail by throwing ExceptionInInitializerError

Re: RFR [14/java.xml] 7148925: StAXSource causes exceptions to be thrown with certain wellformed XML instances

On 7/9/19 3:07 PM, Lance Andersen wrote: Hi Joe, Overall, this looks good. Thanks Lance! Please add the bug number to the top @bug in the test class. Added. I might have defined all of the elements in the DataProvider “xml” in separate String objects to make it easier to read, but

RFR [14/java.xml] 7148925: StAXSource causes exceptions to be thrown with certain wellformed XML instances

Please review a fix for an Exception caused by StAXSource. The fix adds code that processes the prolog and misc content as specified by the XML specification, and removes the code that made incorrect assumption about XML document structure. https://bugs.openjdk.java.net/browse/JDK-7148925

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

Would the SecurityManager need to for permissions (checkWrite or some new permission) before cancelDeleteOnExit() is allowed? Jason From: core-libs-dev on behalf of Brian Burkhalter Sent: Tuesday, July 9, 2019 1:08 PM To: core-libs-dev Subject: Re:

JDK 14 RFR of JDK-8202385: Annotation to mark serial-related fields and methods

Hello, Returning to some old work [1], please review the addition of a java.io.Serial annotation type for JDK 14 to mark serial-related fields and methods:     webrev: http://cr.openjdk.java.net/~darcy/8202385.3/     CSR: https://bugs.openjdk.java.net/browse/JDK-8217698 Thanks, -Joe [1]

Re: RFR [14/java.xml] 7148925: StAXSource causes exceptions to be thrown with certain wellformed XML instances

Hi Joe, Overall, this looks good. Please add the bug number to the top @bug in the test class. I might have defined all of the elements in the DataProvider “xml” in separate String objects to make it easier to read, but no big deal and does not need changed prior to pushing. > On Jul 9,

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

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 considered to be some sort of security issue.

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

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 thought that webrev.02 had superseded it. Looking