hg: lambda/collections/jdk: 2 new changesets

[Brian Goetz]

Yes, that's right.  I see several sensible categories here:
  - Serial/Eager -- operations on collections that eagerly produce new 
collections (a few of which were implemented here)
  - Serial/Lazy -- stream-like operations on collections that can be 
easily pipelined, and then converted to / dumped into collections at the 
tail end of the pipeline
  - Parallel/Lazy -- operations on collections that can be parallelized 
(e.g., filter/map/reduce) and possibly jammed so that a pipeline of 
parallel operations (filter/map/reduce) can be combined into a single 
compound operation that executes in a single parallel pass (a la 
ParallelArray)

The JSR 166 Expert Group (the friendly folks who brought you 
ThreadPoolExecutor and ConcurrentHashMap!) will be developing these APIs.

On 2/23/2011 11:11 AM, Paul Benedict wrote:
> The name of SerialEagerCollections is reminiscent of the eager/greedy,
> reluctant, and possessive qualifiers in regex -- different algorithms,
> in essence. I assumed other algorithms would be following.
>
> On Wed, Feb 23, 2011 at 9:55 AM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     You beat me to the part where I explain what these changes actually are
>     supposed to be.  What you're seeing is the first end-to-end
>     demonstrations of extension methods in action!
>
>     For the time being, this repository (lambda-collections) is completely
>     experimental.  Do not take anything that happens here as an indication
>     of what the APIs (or implementations) are going to look like.  (This is
>     the downside of working in the open; everything that gets checked in is
>     assumed to be perfect and final; things in this repo are neither and
>     won't be for a long time.)
>
>     Rather than start with the hard part (parallel/lazy aggregate
>     operations), this changeset demonstrates the simplest serial/eager
>     collection->collection operations, which is the least interesting (and
>     least efficient) corner of the lambda-enabled collections strategy.
>
>     The interesting takeaway here is that there is a simple set of JUnit
>     test cases that compile with the lambda-enabled compiler and run using
>     the bytecode weaver tool that Robert Field has been working on.  This
>     represents the first end-to-end demonstration of extension methods
>     working in the compiler, libraries, and VM (though the VM is being faked
>     out by a build-time weaving tool, which is just an intermediate step,
>     useful for refining the defender resolution algorithms before we start
>     hacking the VM.)
>
>
>     I'll address your entirely valid API design suggestions separately (but
>     probably not for a while.)
>
>
>     On 2/23/2011 8:15 AM, Thomas Münz, XDEV Software Corp. wrote:
>      > If I may:
>      > I browsed the source code a little because I'm very interested in
>     how the JDK collections will get enhanced for functional
>     programming, internal iteration, etc.
>      > Background is: I wrote my own collections framework to replace
>     the JDK collections (for many reasons of dissatisfaction with what's
>     there, but that's not the issue here, of course)
>      >
>      > I came accross the new Collection method
>      > Collection<E>  filter(Predicate<? super E>  filter)
>      >
>      > and it's defender delegate in SerialEagerCollections:
>      >
>      > public static<E>  Collection<E>  filter(Collection<E>
>       collection, Predicate<? super E>  predicate) {
>      > return filterTo(collection, new ArrayList<E>(), predicate);
>      > }
>      >
>      > and then accross the comment:
>      > // Much work remains in the area of choosing the correct type of
>     collection to construct.
>      >
>      >
>      > I had the exact same problem when designing the "XCollection"
>     interfaces. I started out with the same "filter(Predicate<? super E>
>       filter)" and ended with a very unsatisfying "new ArrayList<E>()"
>     as an implementation detail.
>      > To cut a long story short: as fancy as ".filter()" might look, it
>     turned out that it is too concrete and the following is much more
>     convenient and flexible in practice (seperating concearns more clearly):
>      >
>      > public<C extends Collecting<? super E>>  C copyTo(C target,
>     Predicate<? super E>  predicate);
>      >
>      > (Collecting<E>  is a simple interface reabstracting the boolean
>     add(E element) method to provide more flexibility for my SQL-like
>     Collection-querying framework. For JDK collections, one could put
>     Collection<? super E>  there as well, of course)
>      > This way, the very same method can do the following things:
>      >
>      > final ArrayList<Person>  newPersonList = persons.copyTo(new
>     ArrayList<Person>(), myPredicate);
>      >
>      > final HashSet<Person>  newPersonSet = persons.copyTo(new
>     HashSet<Person>(), myPredicate);
>      >
>      > persons.copyTo(alreadyExistingTargetCollection, myPredicate)
>      >
>      > myCollectionFactory.toNewInstance(persons, myPredicate)
>      >
>      >
>     this.doSomethingElseWith(persons.copyTo(alreadyExistingTargetCollection,
>     myPredicate));
>      >
>      > etc. ...
>      >
>      > In the end, I found that it's almost never desireable to have a
>     (general purpose) collection implementation decide on its own which
>     type of collection one has to use in the application code. The
>     filter(predicate) variant would be just another method next to
>     copyTo(target, predicate) to bloat method count but be of very
>     little use (or even dangerous and thus adverse, given that the
>     implementation-decided collection type might change silently)
>     compared to it.
>      >
>      >
>      > Don't know if it's bumptious (<- funny word from the translator
>     website) to tell the "pros" how to design their interfaces ;), but
>     back then it turned out to be cleaner architecture that way for me
>     (although losing the fancy "filter()"-like looks :) ), so I just
>     thought throwing it in might help.
>      > There'd be similar findings regarding collections in general and
>     their enhancement towards functional programming, performance,
>     functionality, etc., but I guess I'd make myself pretty obnoxious
>     pretty quick once getting started :-D (and it'd be off-topic here as
>     well).
>      >
>      >
>      > Regards,
>      > Thomas
>      >
>      >
>      >
>      > Subject: hg: lambda/collections/jdk: 2 new changesets (Tue Feb 22
>     16:01:45 PST 2011)
>      > From: brian.goetz at oracle.com <http://oracle.com> brian.goetz
>     at oracle.com <http://oracle.com>
>      >
>      >> Changeset: 63693b18adef
>      >> Author:    briangoetz
>      >> Date:      2011-02-22 19:00 -0500
>      >> URL:>
>     http://hg.openjdk.java.net/lambda/collections/jdk/rev/63693b18adef
>      >>
>      >> Add SAM types Block,Predicate,Reducer,Mapper; add simple
>     forEach/filter/map/reduce methods to Collection,List,Set with simple
>     serial/eager implementations; add simple test suite (1 suppressed
>     failure)
>      >>
>      >> + defender-tests/build.xml
>      >> + defender-tests/src/SerialEagerCollectionsTest.java
>      >> ! make/common/shared/Defs-java.gmk
>      >> ! make/java/java/FILES_java.gmk
>      >> ! src/share/classes/java/util/Collection.java
>      >> ! src/share/classes/java/util/List.java
>      >> + src/share/classes/java/util/SerialEagerCollections.java
>      >> ! src/share/classes/java/util/Set.java
>      >> + src/share/classes/java/util/sam/Block.java
>      >> + src/share/classes/java/util/sam/Mapper.java
>      >> + src/share/classes/java/util/sam/Predicate.java
>      >> + src/share/classes/java/util/sam/Reducer.java
>      >>
>      >> Changeset: f6dceeefc7c4
>      >> Author:    briangoetz
>      >> Date:      2011-02-22 19:01 -0500
>      >> URL:
>     http://hg.openjdk.java.net/lambda/collections/jdk/rev/f6dceeefc7c4
>      >>
>      >> Merge
>      >
>      >
>      >
>
>