Re: Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member

On 26/07/2019 22:12, Mandy Chung wrote: Debug VM checks if a class is accessible to the lookup class except if the lookup class is java.lang.Object (which was the lookup class of publicLookup previously). WithJDK-8173978, Lookup::in has changed and it can be used to create a new public Lookup o

New candidate JEP: 358: Helpful NullPointerExceptions

https://openjdk.java.net/jeps/358 - Mark

Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member

Debug VM checks if a class is accessible to the lookup class except if the lookup class is java.lang.Object (which was the lookup class of publicLookup previously). WithJDK-8173978, Lookup::in has changed and it can be used to create a new public Lookup on a different lookup class. A quick fix

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

> On 26 Jul 2019, at 19:36, Alan Bateman wrote: > > > > In any case, the change looks okay but it might be simpler to restructure to > use: > > while (in != null) { > try { in.close() } catch (IOException e) { ... } > peekNextStream(); > } > > to simplify the error handling and avoid

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

> On 26 Jul 2019, at 19:36, Alan Bateman wrote: > > The bug summary might be a big misleading as SequenceInputStream isn't thread > safe and close isn't atomic. The changes are really to attempt to close all > the remaining streams rather than bailing out when closing one of them fails. I'm no

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

> On Jul 26, 2019, at 11:36 AM, Alan Bateman wrote: > > On 26/07/2019 16:41, Brian Burkhalter wrote: >> : >> Please see the updated patch which switches the implementation to the >> amended version and incorporates the proposed change to the test: >> >> http://cr.openjdk.java.net/~bpb/8078891

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

On 26/07/2019 16:41, Brian Burkhalter wrote: : Please see the updated patch which switches the implementation to the amended version and incorporates the proposed change to the test: http://cr.openjdk.java.net/~bpb/8078891/webrev.01/ The bug summary might be a big misleading as SequenceInputStr

Re: RFR 8226808: PreparedStatement javadoc typo

++1 Brian > On Jul 26, 2019, at 11:29 AM, Joe Wang wrote: > > +1, and +1 for the salary at the time of JDK 1.1 ;-) > > -Joe > > On 7/26/19 11:17 AM, Lance Andersen wrote: >> Hi all, >> >> Please review this trivial change for JDK-8226808 which corrects a javadoc >> error that dates back to

Re: RFR 8226808: PreparedStatement javadoc typo

+1, and +1 for the salary at the time of JDK 1.1 ;-) -Joe On 7/26/19 11:17 AM, Lance Andersen wrote: Hi all, Please review this trivial change for JDK-8226808 which corrects a javadoc error that dates back to JDK 1.1 where the example for BigDecimal is not correct: — $ hg diff diff -r 5

Re: [14] RFR: 8228465: HOST locale provider holds wrong era name for GregorianCalendar in US locale

Hi Naoto, This looks good > On Jul 26, 2019, at 2:03 PM, naoto.s...@oracle.com wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8228465 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8228465/web

RFR 8226808: PreparedStatement javadoc typo

Hi all, Please review this trivial change for JDK-8226808 which corrects a javadoc error that dates back to JDK 1.1 where the example for BigDecimal is not correct: — $ hg diff diff -r 550a1a6ca596 src/java.sql/share/classes/java/sql/PreparedStatement.java --- a/src/java.sql/share/classes/j

[14] RFR: 8228465: HOST locale provider holds wrong era name for GregorianCalendar in US locale

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8228465 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8228465/webrev.00/ Similar issue was reported with JDK-8039301, in which Calendar.getDisplayName() method was modifie

Re: Review Request: JDK-8209005: Lookup.unreflectSpecial fails for default methods when Lookup.findSpecial works

Daniel noticed that `unreflectSpecial` is missing in the "Lookup Factory Methods" section in the class spec.  In fact there are a duplicated `lookup.unreflect(aMethod)` row that might originally be for `unreflectSpecial`.   I fix the javadoc in this patch: http://cr.openjdk.java.net/~mchung/jd

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

On 26/07/2019 17:41, Brian Burkhalter wrote: Please see the updated patch which switches the implementation to the amended version and incorporates the proposed change to the test: http://cr.openjdk.java.net/~bpb/8078891/webrev.01/ That looks good to me Brian. I had a look at the API documen

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

> On Jul 26, 2019, at 4:14 AM, Pavel Rappo wrote: > > […] I prefer the amended version. As it > both does the job and preserves the original behavior when consuming data from > the current component stream. > > […] > > A nit on the accompanying test. Please consider this change: Please see t

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Hello core-lib-dev, I think it is a mistake to make `AbstractSet#removeAll` use the membership semantics of the argument collection instead of those of the receiver set, and to iterate over the receiver instead of the argument collection. I think that there are much stronger arguments for doing i

Re: RFR: JDK-8227684 : jpackage must handle win32 mangled names in jli.dll

On 7/25/2019 5:29 PM, Alexander Matveev wrote: Do you know if all 32-bit builds will have "_JLI_Launch@56"? Also, I think @56 is ordinal which can be used to load function by this number instead of the name, so I do not think you need to specify it. My suggestion is to try "JLI_Launch" firs

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

> On 25 Jul 2019, at 21:01, Brian Burkhalter > wrote: > This concern would be fixed by changing the proposed patch as > > --- a/src/java.base/share/classes/java/io/SequenceInputStream.java > +++ b/src/java.base/share/classes/java/io/SequenceInputStream.java > @@ -91,13 +91,10 @@ > * Con

Re[2]: Benchmarking of new optimized Dual-Pivot Quicksort

Hi Laurent, Many thanks for feedback! I run tests on two computers under Windows (8 processors) and Linux (88 processors). The details of the first computer is: Window 10 (64-bit), Intel Core i7 8650U 1.90 GHz and output of "uname -a" command for the second computer is: Linux rho 4.15.0-54-gen

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

Hi Brian, On 7/26/19 12:42 AM, Brian Burkhalter wrote: On Jul 11, 2019, at 12:52 AM, Peter Levart > wrote: On 7/11/19 9:47 AM, Peter Levart wrote: http://cr.openjdk.java.net/~plevart/jdk-dev/8193072_File.undoDeleteOnExit/webrev.02/ Another thing to consider

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

Hi all, I updated the DPQS patch thanks to latest release from Vladimir ([image: Pièces jointes]2019.07.25): http://cr.openjdk.java.net/~lbourges/dpqs/dpqs-8226297/dpqs-8226297.1/ " Updated version of Arrays and DualPivotQuicksort files, the summary of changes: 1. Corrected minimal threshold for

Re: Benchmarking of new optimized Dual-Pivot Quicksort

Hi Vladimir, First Thank you for these impressive results: 15% to 70% overall gains is amazing and will make a big difference, Congratulations ! Could you publish the different test environment ? - HW: cpu (lscpu output) - OS version - JDK version + JVM settings Ideally you or I could write a sh