Hi
Requesting review for some basic functionality related to lambdas -
Add min, max, sum methods to the primitive wrapper classes - Byte,
Short, Integer, Long, Float, Double and Character so as to be able to
use them as reducers in lambda expressions. Add and, or, xor methods to
Boolean.
ht
This patch adds a constructor to ThreadLocal to supply initial values
using the new Supplier functional interface. Please review. This work
was done by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003246
Thanks
rmation as to why you disagree?
Thanks
Thanks,
David
-
On 1/12/2012 4:44 AM, Akhil Arora wrote:
Hi
Requesting review for some basic functionality related to lambdas -
Add min, max, sum methods to the primitive wrapper classes - Byte,
Short, Integer, Long, Float, Double and Character so
On 12/06/2012 03:32 AM, Doug Lea wrote:
These seem like really good reasons to implement as you
suggested in last post, with a static factory that uses a non-public
*final* subclass that wires initialValue to supplier call,
and not otherwise modifying the ThreadLocal class.
It has the added bene
On 12/06/2012 09:38 AM, Doug Lea wrote:
Much better; thanks!
As a minor matter, it probably makes sense to give that class a
name. Even though it is a non-public static class, the name
will be seen here and there by debuggers, stacktraces, etc,
and the default "$" name will be confusing. As in:
On 12/05/2012 09:10 PM, David Holmes wrote:
Was there a CCC request for this?
Yes, a CCC was submitted on Nov 12, but it was deferred pending a
discussion on this alias. I just updated and resubmitted the CCC based
on Doug and Remi's suggestions.
On 12/06/2012 11:02 AM, Remi Forax wrote:
just nitpicking,
return new SuppliedThreadLocal(supplier);
should be
return new SuppliedThreadLocal<>(supplier);
Also, can you add a @see in the constructor of ThreadLocal that
references ThreadLocal.withInitialValue(Supplier).
http://cr.openj
As part of the Library Lambdafication, this patch adds the following
default methods to Collections -
Iterable.forEach(Block)
Collection.removeAll(Predicate)
List.sort(Comparator)
List.replaceAll(UnaryOperator)
It also provides more efficient implementations of these methods for
ArrayList, Vec
Updated with yours and Alan's comments -
http://cr.openjdk.java.net/~akhil/8001647.2/webrev/
- removed null check for removeSet
- cache this.size in removeAll, replaceAll
(for ArrayList, Vector and CopyOnWriteArrayList)
- calculate removeCount instead of BitCount.cardinality()
- removed unnece
needs to be more than just a set of raw double
additions, but that can be tackled later.
Cheers,
-Joe
On 12/5/2012 1:27 PM, Akhil Arora wrote:
Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/
- delegate to Math.min/max for int/long/float/double
- rename Boolean.and/or/xor to logic
http://cr.openjdk.java.net/~akhil/8001647.3/webrev/
- now with synchronized and unmodifiable wrappers in Collections.java
for the default methods being added
On 12/10/2012 01:48 PM, Akhil Arora wrote:
Updated with yours and Alan's comments -
http://cr.openjdk.java.net/~akhil/8001
http://cr.openjdk.java.net/~akhil/8004201.3/webrev/
- removed these operators on Byte and Short
- javadoc improvements based on CCC review
On 12/10/2012 03:45 PM, Akhil Arora wrote:
http://cr.openjdk.java.net/~akhil/8004201.2/webrev/
- replaced "Suitable for conversion as a method refe
As part of the library lambdafication, this patch adds a forEach default
method to Iterator, and converts remove() into a default method so that
implementations of Iterator no longer have to override remove if they
desire the default behavior, which is to throw an
UnsupportedOperationException.
looks good
On 01/31/2013 07:32 PM, Kumar Srinivasan wrote:
Hi Akhil, Jayashree,
Please verify, I have modified the tests.
http://cr.openjdk.java.net/~ksrini/8006536/webrev.0/
Thanks
Kumar
Hi Mike,
a few small things -
UnmodifiableMap.forEach
is missing Objects.requireNonNull(action);
EmptyMap.replaceAll(BiFunction)
should just return instead of throwing UnsupportedOpEx
particularly since EmptyList.replaceAll also returns silently
after checking if function is null to ful
Looks like the stars are aligning on getting on this into TL... the
refreshed webrev is -
http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
Please review
Thanks
On 12/10/2012 09:31 PM, Akhil Arora wrote:
http://cr.openjdk.java.net/~akhil/8001647.3/webrev/
- now with synchronized and
Please review the addition of optimized defaults for Iterator's
forEachRemaining to ArrayList, LinkedList, Vector and
CopyOnWriteArrayList. The unit test has a performance comparison test
(disabled by default) that measures the difference between this method
and hasNext()/next(). Significant im
Updated with feedback so far -
http://cr.openjdk.java.net/~akhil/8001647.9/webrev/
On 04/18/2013 11:49 AM, Akhil Arora wrote:
Looks like the stars are aligning on getting on this into TL... the
refreshed webrev is -
http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
Please review
Thanks
- I am now preferring the Iterator return from DataProvider though I haven't
made an on-demand provider yet. You could also mark your DataProvider as ", parallel =
true"
added parallel
On Apr 18 2013, at 11:49 , Akhil Arora wrote:
Looks like the stars are aligning on getti
On 04/19/2013 04:15 AM, Alan Bateman wrote:
On 18/04/2013 19:49, Akhil Arora wrote:
Looks like the stars are aligning on getting on this into TL... the
refreshed webrev is -
http://cr.openjdk.java.net/~akhil/8001647.8/webrev/
A minor comment on Collection.removeIf is "that satisifie
On 04/19/2013 05:42 AM, David Holmes wrote:
On 19/04/2013 10:14 PM, Paul Sandoz wrote:
On Apr 19, 2013, at 1:15 PM, Alan Bateman
wrote:
On 18/04/2013 19:49, Akhil Arora wrote:
Looks like the stars are aligning on getting on this into TL... the
refreshed webrev is -
http
On 04/21/2013 04:33 AM, Alan Bateman wrote:
On 20/04/2013 02:39, Akhil Arora wrote:
On 04/19/2013 04:15 AM, Alan Bateman wrote:
On 18/04/2013 19:49, Akhil Arora wrote:
Looks like the stars are aligning on getting on this into TL... the
refreshed webrev is -
http://cr.openjdk.java.net/~akhil
On 04/20/2013 01:42 PM, Ulf Zibis wrote:
Am 20.04.2013 01:59, schrieb Akhil Arora:
Please review the addition of optimized defaults for Iterator's
forEachRemaining to ArrayList, LinkedList, Vector and
CopyOnWriteArrayList. The unit test has a performance comparison test
(disabled by de
On 04/22/2013 11:42 AM, Alan Bateman wrote:
On 20/04/2013 00:59, Akhil Arora wrote:
Please review the addition of optimized defaults for Iterator's
forEachRemaining to ArrayList, LinkedList, Vector and
CopyOnWriteArrayList. The unit test has a performance comparison test
(disabled by de
On 04/24/2013 06:19 AM, Alan Bateman wrote:
On 23/04/2013 20:18, Akhil Arora wrote:
On 04/22/2013 11:42 AM, Alan Bateman wrote:
One thing I meant to ask when forEachRemaining was added was whether it
should say anything about the "last element"? I see in the webrev that
you've
On 04/26/2013 04:52 AM, Paul Sandoz wrote:
On Apr 24, 2013, at 7:57 PM, Remi Forax wrote:
On 04/24/2013 07:24 PM, Akhil Arora wrote:
On 04/24/2013 06:19 AM, Alan Bateman wrote:
On 23/04/2013 20:18, Akhil Arora wrote:
On 04/22/2013 11:42 AM, Alan Bateman wrote:
One thing I meant to ask
Looks good to me. I have had to add similar print statements when
debugging, but I deleted them before committing, to keep the default
test output clean.
Minor - it would be good to have a little more consistency... some tests
print the class name always, some only on failure. Also would be go
looks good
On 05/24/2013 04:01 PM, Kumar Srinivasan wrote:
After some hallway conversation with Akhil, I added some more tests
with progressive number of \ handling, just to make sure, besides that
there
are no other changes.
full webrev:
http://cr.openjdk.java.net/~ksrini/8007333/webrev.1/
de
28 matches
Mail list logo
