Round 2 feedback

[Remi Forax]

On 02/10/2013 01:34 AM, Michael Nascimento wrote:
> Hi guys,

Hi Mickael,

>
> So I've updated my code to b76. Some unstructured feedback:
>
> - We use many Maps here, with many transformations. It is still painful to
> do operations like transformValues, because it usually involves using other
> lambdas and then type inference fails, still requiring specificying the
> actual type parameters - and this might require many parameters sometimes;
> - At least here, even simple transformations such as
> myCollection.parallelStream().map(Functions.string()).collect(Collectors.<String>toList())
> requires the explicit types;

Weird,
this works for me:
   import static java.util.stream.Collectors.*;

   static class Functions {
     static Function<Object, String> string() {
       return Object::toString;
     }
   }

   public static void main(String[] args) {
     Arrays.stream(args).map(Functions.string()).collect(toList());
   }

how Functions.string() is defined ?

> - groupingBy that returns a Map keyed by the Stream type is completely
> unintuitive. If not by the suggestion from the mailing list, I would never
> think of it as being applicable to my use case. A better name is certainly
> desirable;
> - It seems odd to have collect and collectUnordered when some Collectors
> are naturally unordered, such as toSet. Can't it be changed to be a
> property of the Collector somehow?;
> - computeIfAbsent is useful, but for most Guava cases I wanted to lambdify
> I actually needed a method that returns an Optional instead. Can it be
> added?;
> - Here is my greatest concern so far: parallel streams in their current
> form will cause Java EE applications to fail miserably. In such
> environments, threads cannot be freely created and all types of leaks and
> exceptions can happen if one calls a method in a non-container managed
> thread. Since calling parallelStream is cheap, I guess people will do it
> often and it will be hard for Java EE developers to find out if any
> third-party Java SE 8 code is safe to call or not - and enterprise
> developers unaware of such restrictions, which are unfortunately the
> majority, will be puzzled by never seen exceptions or erratic behaviour in
> production. My suggestion would be to add a parameter to parallelStream and
> parallel which is an abstraction to thread management,  forcing people to
> think about it. Then one can construct a wrapper over the
> container-specific API for now and Java EE 8 can provide the standardized
> one;

yes, the issue is even more complex than that when people will start to 
use parallelStream() inside library codes because the library will work 
in Java SE and not with Java EE.
The real question seems to be how JEE container can support the common 
ForkJoinPool.

> - Some throw-away Javadoc could be added, especially to Collectors, only
> with sample code for a Person class so developers can understand what
> methods are supposed to do.
>
> I would like to congratulate you all for the fast responses.
>
> Regards,
> Michael
>

cheers,
Rémi