forEach with a method reference,
which IIRC might be slightly better than having a lambda. The underlying
collection (let’s say ArrayList) will be called which will also not create an
iterator but iterate directly over the ArrayList internal array.
Thanks,
Don
> Thanks!
>
> /Claes
&g
The following code:
for (CharSequence cs: elements) {
joiner.add(cs);
}
Can be replaced with:
elements.forEach(joiner::add);
This would have the minor benefit of making it safe to use String.join with
synchronized collections without requiring a client side lock. There are likely
other
> collection is non-empty, as you can append into single collection from
> existing sources. Essentially, into(c) == forEach(c::add), but it's
> also possible to add optimizations for specific collections (like `if
> (isSizedStream() && c instanceof ArrayList al) {
> al.ensure
(so much so, in fact, that people are often frustrated by our seeming
> conservatism.)
>
>
>
>
>
>
>
> On 4/30/2021 4:02 PM, Donald Raab wrote:
>> There is a default method getAny defined on the RichIterable interface in
>> Eclipse Col
There is a default method getAny defined on the RichIterable interface in
Eclipse Collections. Adding a getAny with the same signature to Collection is
bound to cause a break similar to CharSequence.isEmpty did with JDK 15 but
possibly more extensive since RichIterable is the parent interface
MutableBiMap biMap =
stream.to(array -> ArrayAdapter.adapt(array)
.toBiMap(String::toLowerCase, String::toUpperCase));
Thanks,
Don
> On Apr 27, 2021, at 1:35 AM, Donald Raab wrote:
>
> I realized after sending that option 2 can be made more abstract:
>
&
I realized after sending that option 2 can be made more abstract:
default > R to(Function function)
{
return function.apply((T[]) this.toArray());
}
>
> 2. Pass the result of toArray directly into a function that can then return a
> Collection. This should work with Set.of, List.of and any
Hi all,
I’d like to propose adding one or two of the following methods on Stream to
cover more surface area of the Collections ecosystem, without requiring a big
increase in the size of the Stream interface. Apologies if this has come up for
discussion before.
1. Stream contents into a
> I'm also concerned about conflicts over the other method names; something
> like addFirst() is a pretty obvious method to add to a custom List
> implementation. I haven't seen any, but that doesn't mean there aren't any.
>
> s'marks
The getFirst() and getLast() methods will have
> On Apr 17, 2021, at 2:24 PM, Stuart Marks wrote:
>
>
>
> On 4/16/21 3:06 PM, Donald Raab wrote:
>> We should be cautious when adding new APIs to existing interfaces. There may
>> be libraries which extend JDK types and already have reversed(),
>>
Hi Stuart,
We should be cautious when adding new APIs to existing interfaces. There may be
libraries which extend JDK types and already have reversed(), toReversed() or
asReversed() APIs and corresponding interfaces.
There are OrderedIterable and ReversibleIterable interfaces and asReversed()
I have been reading previous threads, the original bug request, and exploring
the javadoc and implementation of toList() on Stream in JDK 16. I don’t want to
waste time rehashing previous discussions, but I want to understand and
prioritize the motivation of this change, and propose what I
12 matches
Mail list logo
