On May 27 2013, at 06:05 , Doug Lea wrote: > On 05/24/13 23:17, Mike Duigou wrote: > >> There's an awful lot here! > > (It's been a long time since jdk7 :-) > >> >> - It was surprising (and somewhat disappointing) to see changes like the >> following in various places. Is iterator creation that expensive? I'd hate >> to have to go back to using old style for loops everywhere. >> >> - List<Future<T>> futures = new ArrayList<Future<T>>(tasks.size()); >> + ArrayList<Future<T>> futures = new >> ArrayList<Future<T>>(tasks.size()); >> > > Are you suggesting that we not improve performance? :-) > Waiting a decade in wishful-thinking mode about ArrayList > traversal seems long enough.
Nope, merely feeling the same disappointment that using the old style iteration is necessary. > (Aside: We addressed this in stream Spliterators to the > extent possible at library level. ArrayList.forEach of a fully > resolved non-capturing lambda is around twice as fast > as iterators.) > >> >> - The default for getOrDefault() in ConcurrentMap shouldn't be removed. >> >> - CopyOnWriteArraySet currently has an ORDERED spliterator. Set is not >> normally order preserving. >> > > Thanks! Both the results of my not rechecking vs lambda versions > (where a lot of this code has been running for a while now). > Hopefully no other three-way diffs of jsr166, lambda, tl > fell between cracks. I will be especially watchfully this. Comparing this patch applied to TL versus current Lambda was one of the checks I plan to make before completing approval of this issue. Mike
