Re: RFR 8191216: SimpleTimeZone.clone() has a data race on cache fields

Hi Naoto, Thank you for reviewing. Naoto Sato je 06. 12. 2017 ob 20:41 napisal: Hi Peter, Venkat, Thank you for the fix. It looks good to me. Improved performance is a nice bonus! Would you be able to provide with a regression test? Sure, here it is: http://cr.openjdk.java.net/~plevart/jdk

Re: RFR(s): 8177681: Remove methods Runtime.getLocalized{Input, Output}Stream

That must be oddly satisfying :-D Cheers, Martijn On 7 December 2017 at 03:35, wrote: > 2017/12/6 17:33:36 -0500, stuart.ma...@oracle.com: > > Please review the removal of these methods, which were part of an > obsolete > > internationalization mechanism. They were deprecated in JDK 1.1 and > d

Re: RFR 4358774: Add null InputStream and OutputStream

Hi Brian, > All previous suggested changes have been made in > > http://cr.openjdk.java.net/~bpb/4358774/webrev.03/ > 99 @Override 100 public int read(byte[] b, int off, int len) throws IOException { 101 Objects.checkFromIndexSize(off, len, b.length)

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Peter Levart je 09. 12. 2017 ob 21:01 napisal: Hi Claes, Claes Redestad je 09. 12. 2017 ob 03:19 napisal: Hi John, On 2017-12-09 02:20, John Rose wrote: On Dec 8, 2017, at 4:45 PM, John Rose > wrote: Can anyone point out a reason why the value based lists of

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Claes, Claes Redestad je 09. 12. 2017 ob 03:19 napisal: Hi John, On 2017-12-09 02:20, John Rose wrote: On Dec 8, 2017, at 4:45 PM, John Rose > wrote: Can anyone point out a reason why the value based lists of List.of() should serialize while the value based l

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Claes, > For example, returning Spliterators.emptySpliterator() and > Collections.singletonSpliterator when appropriate *sounds* like nice little > optimizations, but Arrays.spliterator(T[]) with an empty or single-element > array > appears to be relatively cheap operations, whereas mixing imp

Re: Add EnumMap.keyType() and EnumSet.elementType()

Hi Rémi, > It's like exposing reified type arguments, i can see these kind of change > back firing in at least two ways. > It's not future proof, part of valhalla requires to change generics to allow > generics of value types which requires a form of reification, but we may end > up with a ligh

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Andrej, forEach seems like a no-brainer, but spliterator might require some extra care. For example, returning Spliterators.emptySpliterator() and Collections.singletonSpliterator when appropriate *sounds* like nice little optimizations, but Arrays.spliterator(T[]) with an empty or single-

Re: Add EnumMap.keyType() and EnumSet.elementType()

Hi Andrej, I do not think it's a good idea. It's like exposing reified type arguments, i can see these kind of change back firing in at least two ways. It's not future proof, part of valhalla requires to change generics to allow generics of value types which requires a form of reification, but w

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Claes, > One more thing: Could you please add specialised implementations also > for the following methods: > > List.forEach(Consumer) > > List.spliterator() > For List12 when List12.size() == 1 please use > Collections.singletonSpliterator() > (this method should be moved to the Spliterat

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Claes, > I think one can interpret the @implSpec in AbstracList::subList to suggest > that the implementation retrieved will subclass AbstractList, which implies > it's *not* Serializable. Not for me. java.util.ArrayList is a subclass of AbstractList and is serializable. And you can use j.u.A

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

On 8 December 2017 at 00:33, Stuart Marks wrote: > Please review this changeset that introduces a new no-arg method > orElseThrow() to Optional, as a preferred alternative to the get() method. I am willing to accept this addition as it has an obvious parallel to the existing supplier method. My