Re: Collections.emptyList().sort() does nothing

I would however vote for allowing an empty list to be sorted. This is such a common case to return a replacement empty list that it will not only introduce changed behavior but also forces ugly code. For singleton list I can kind of understand that you want to fail early, but it could be made t

Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

On 15.11.2017 6:19, Paul Sandoz wrote: On 10 Nov 2017, at 01:36, stanislav lukyanov wrote: On 10.11.2017 0:13, Paul Sandoz wrote: <...> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don’t want that to side-track the r

Re: Collections.emptyList().sort() does nothing

Different maintainers of the core library differed on whether it's important to pedantically check for such corner case mistakes. Recently the trend has been to check for all errors up front, even if it ends up making no difference. Users should not depend on the library implementer's mood or vig

Collections.emptyList().sort() does nothing

Hello! According to `List.sort` specification [1] "This list must be modifiable". According to `Collections.emptyList` specification [2] "Returns an empty list (immutable)." So I assume that `List.sort` cannot be called on `Collections.emptyList` result. However in fact this call is allowed doing

Re: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean

I am wondering this ACE comes from Graal accessing jdk.vm.ci.services from JVMCI which is defined to the boot loader versus Graal is defined to the platform class loader.  java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.jdk.vm.ci.services

Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants

> On 10 Nov 2017, at 01:36, stanislav lukyanov > wrote: > > On 10.11.2017 0:13, Paul Sandoz wrote: >> <...> >> I would prefer to follow up later on with more non-normative explanatory >> text. It will take some careful crafting and i don’t want that to side-track >> the review for the moment

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

On 14 November 2017 at 23:58, Naoto Sato wrote: > So even with the new suggested method, > > formatter.withZone(locale).withLocalization(locale) > formatter.withLocalization(locale).withZone(locale) > > would produce different formatters. Would it be OK, assuming along with some > proper documenta

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

> On 11 Nov 2017, at 07:58, Stefan Zobel wrote: > > In CustomFJPoolTest#testCustomPools() > >>> assertEquals(splitsForPC, splitsForPHalfC * 2); > > > I'm sure I'm slow on the uptake, but isn't this bound to > fail for every commonParallelism == 2^n + 1 in the closed > range [2, 127], i.e.,

Re: RFR: 8187954 Update JAX-WS RI integration to latest version

Hi Lance Is there any other issue about it? can you approve it to merge? > On Nov 6, 2017, at 07:59, ZhengJun Li wrote: > > > Yes, all the tests are passed. > > > 在 2017年11月6日，05:05，Lance Andersen > 写道： > >> Hi Jack, >> >> Overall looks OK. I am assuming

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

Thanks, Stephen. On 11/14/17 3:22 PM, Stephen Colebourne wrote: I'd missed that this affects java.time.* I believe that the changes to DateTimeFormatter are a mistake and will cause confusion. Currently, each withXxx() method is independent - they do not interact and operate on a single piece o

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

Thanks, Lance. On 11/14/17 2:34 PM, Lance Andersen wrote: Hi Naoto DateTimeFormatter.java, DateTimeFormatterBuilder.java, WeekFields.java., Calendar.java, Currency.java (and others) —— 136 * the chronology and/or the zone are also overriden. If both "ca" and "rg" are 137 * specified, t

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

Thanks, Roger. On 11/14/17 1:28 PM, Roger Riggs wrote: Hi Naoto, A few comments, there is lots here to review. tools/cldrconverter/LDMLParseHandler.java: - 948: TODO? Will remove it. DateFormatSymbols.java:  - 88: "overriden" -> "overridden" DecimalFormatSymbols:  - 60: "rg" -> "nu"?

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

I'd missed that this affects java.time.* I believe that the changes to DateTimeFormatter are a mistake and will cause confusion. Currently, each withXxx() method is independent - they do not interact and operate on a single piece of state. Currently, these two pieces of code have the same effect:

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

Hi Naoto DateTimeFormatter.java, DateTimeFormatterBuilder.java, WeekFields.java., Calendar.java, Currency.java (and others) —— 136 * the chronology and/or the zone are also overriden. If both "ca" and "rg" are 137 * specified, the chronology from "ca" extension supersedes the implicit

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

-- Fs

Re: [10] RFR 8176841: Additional Unicode Language-Tag Extensions

Hi Naoto, A few comments, there is lots here to review. tools/cldrconverter/LDMLParseHandler.java: - 948: TODO? DateFormatSymbols.java:  - 88: "overriden" -> "overridden" DecimalFormatSymbols:  - 60: "rg" -> "nu"?  - 62: "overriden" -> "overridden" NumberFormat.java:  - 106: "a NumberFormat"

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi Peter, On 15/11/2017 1:02 AM, Peter Levart wrote: Hi David, On 11/11/2017 07:51 AM, David Holmes wrote: AFAICS SimpleTimeZone is simply not thread-safe. It has state that can be modified concurrently without synchronization and with fields not even declared volatile. Only the "cache" makes

Re: RFR(M) 8189116: Give the jdk.internal.vm.compiler.management only the permissions it really needs to expose the bean

Try running with -Djava.security.debug=access:domain:failure This will tell you what ProtectionDomain caused the AccessControlException, which should give you a better idea of where the problem is. Look for messages that start with "domain that failed ". --Sean On 11/14/17 1:22 AM, Jaroslav

Re: 8184777: Factor out species generation logic from BoundMethodHandle

Hi Christoph, On 2017-11-14 15:29, Christoph Dreis wrote: I still think it should be called "one integral bound value" instead of "values" and "has" instead of "have" (at least in case a singular species is meant). You seem to have fixed the singular "reference" typo only in ClassSpecializer.j

Re: Faster Math ?

On 09/11/17 09:00, Laurent Bourgès wrote: > The Marlin renderer (JEP265) uses few Math functions: sqrt, cbrt, acos... > > Could you check if the current JDK uses C2 intrinsics or libfdm (native / > JNI overhead?) and tell me if such functions are already highly optimized > in jdk9 or 10 ? > > So

Re: JDK-8067661: transferTo proposal for Appendable

> Am 14.11.2017 um 16:33 schrieb Brian Burkhalter : > > > On Nov 14, 2017, at 3:45 AM, Alan Bateman > wrote: > >> - Readable "hence unspecified". In several other places, including >> InputStream.transferTo, we use "therefore unspecified" and it would be good

Re: JDK-8067661: transferTo proposal for Appendable

On Nov 14, 2017, at 3:45 AM, Alan Bateman wrote: > - Readable "hence unspecified". In several other places, including > InputStream.transferTo, we use "therefore unspecified" and it would be good > to keep that consistent. Mea culpa on the “hence.” > - Readable "Depending on which class impl

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Hi Patrick, On 11/10/2017 09:49 AM, Patrick Reinhart wrote: Hi Stuart, After having thought over your arguments about copyOf versus unmodifiableCopyOf length discussion (also with my colleague) I was thinking about why not create additional X.of(X) methods instead of X.copyOf(X). It would see

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi Venkat, I created the following issue: https://bugs.openjdk.java.net/browse/JDK-8191216 I can also sponsor this patch and push it for JDK 10. The patch that you are proposing looks good to me. Does anybody have anything else to say? Regards, Peter On 11/13/2017 11:28 AM, Venkateswara R

Re: Incorrect validation of DST in java.util.SimpleTimeZone

Hi David, On 11/11/2017 07:51 AM, David Holmes wrote: AFAICS SimpleTimeZone is simply not thread-safe. It has state that can be modified concurrently without synchronization and with fields not even declared volatile. Only the "cache" makes an attempt to use synchronization. So clone() is neve

RE: 8184777: Factor out species generation logic from BoundMethodHandle

Hi Claes, Thanks for incorporating this. > > ClassSpecializer.java > > L510: * For example, a concrete species for two reference and one integral > bound values have a shape like the following: > > Should be imho: > > L510: * For example, a concrete species for two references and one > integral b

Re: 8184777: Factor out species generation logic from BoundMethodHandle

Hi Christoph, On 2017-11-13 18:56, Christoph Dreis wrote: Hey Claes, though far away from being an expert on the subject matter, I have some very minor comments if you don't mind. ClassSpecializer.java L510: * For example, a concrete species for two reference and one integral bound values ha

Re: JDK-8067661: transferTo proposal for Appendable

On 14/11/2017 07:51, Patrick Reinhart wrote: Hi Brian See latest changes here: http://cr.openjdk.java.net/~reinhapa/reviews/8067661/webrev.03 This version mostly looks quite good, a few comments: - Readable "hence unspecified". In several other places, including InputStream.transferTo, we u