Re: BiCollector

The function you propose is just a binary variant of mapping: Collector mapping( Function mapper, Collector downstream); (omitted '? super' for readability) So, it is logical to use the name biMapping: Collector biMapping(

Re: RFR: JDK-8050818 Predicate::not - provide an easier way to negate a predicate

What about "not null" predicate? This is also very common. Right now it is possible via `Objects::nonNull` but many people do not know about this method. So, having a `Predicate.notNull` method would be nice. 2018-05-29 19:52 GMT+07:00 Jim Laskey : > Introduce a new static method Predicate::not

Re: RFR(s): 8203670: unmodifiable List iterator() implementations should not be ListIterators

I agree with Ivan. Isn't it better to create a standalone implementation of Iterator and return its instance in iterator()? Implementing of Iterator for ImmutableList doesn't look like a big problem. 2018-06-26 6:14 GMT+07:00 Ivan Gerasimov : > Hi Stuart! > > Out of curiosity. What if someone

Re: BiCollector

I don't like `distributing` for the same reason as `bisecting`: for me, it sounds like a Stream is giving each collector only a part of elements. 2018-06-19 19:44 GMT+07:00 Brian Goetz : > > > collectingToBoth >> > > This one is actually both evocative of what the method does, and in the >

Re: Possible addition of a default 'getOne' method on Iterable?

Isn't iterable.getOne() the same as iterable.iterator().next()? 2018-01-31 12:15 GMT+07:00 Dave Brosius : > Greetings, > > > sorry if this has been asked before, but has there been any consideration > for adding a > > default T getOne() { > > Iterator it =

Re: BiCollector

I agree that f1 and f2 are unnecessary. I also noticed that toBoth is a binary form of `collectingAndThen`: public static Collector collectingAndThen( Collector downstream, Function finisher); So what about `collectionToBothAndThen`? public static Collector

Re: RFR: JDK-8205461 Create Collector which merges results of two other collectors

tackOverflow where - indepedently of all the others - > I also came up with this type of "dual" *Collector* [3]. I named it > "collectingBoth" there but I'd like to suggest a slightly different name > here. > > I believe that Zheka Kozlov made a great observation about s

Useless null check in HashMap.merge()

I noticed dead code in java.util.HashMap.merge(): public V merge(K key, V value, BiFunction remappingFunction) { if (value == null) throw new NullPointerException(); ... if (value != null) { *// Condition ' value != null' is always true* if (t !=

Re: WeakReference with null referent

I also created an issue in IDEA bug tracker: https://youtrack.jetbrains.com/issue/IDEA-195298. This at least should be handled by an IDE.

WeakReference with null referent

It is possible to create a WeakReference/SoftReference/PhantomReference with a null value in which case the Reference will never be enqueued. This is quite obvious (since null cannot be weakly/softly/phantom reachable). But I think it's worth being mentioned in the JavaDoc. What do you think?

Re: WeakReference with null referent

There are a few valid use cases where `new WeakReference<>(null)` makes some sense. So, we shouldn't forbid nulls. `new WeakReference<>(null, queue)` makes less sense but I bet someone is using this too for some reason. My initial message was not about changing the behavior but only about

Re: Useless null check in HashMap.merge()

Oh yes, you are right. Then this is not dead code, just a useless null check. 2018-07-04 19:55 GMT+07:00 Scott Palmer : > On Jul 4, 2018, at 5:42 AM, Zheka Kozlov wrote: > > > > I noticed dead code in java.util.HashMap.merge(): > > > > pu

Re: [11] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

I noticed that List.copyOf() allocates an array twice. The first allocation is coll.toArray(), the second one is in ListN constructor. Can we do something with it? 2018-03-22 7:51 GMT+07:00 Stuart Marks : > Hi Claes, > > I'm finally finally getting back to this. I

Exceptions in Iterator.forEachRemaining()

Hi everyone. I noticed that different Iterator implementations behave differently when an Exception is thrown inside a Consumer passed to forEachRemaining(): private static void test(List list) { Iterator iterator = list.iterator(); try { iterator.forEachRemaining(i -> {

Re: Stream Method Proposal: long count(Predicate predicate)

findFirst(Predicate predicate) would be nice too чт, 8 нояб. 2018 г. в 8:01, Jacob Glickman : > Hello! > > I see myself having to often call count() as a terminal operation on a > Stream immediately after performing a filter operation. How feasible would > it be to add an overloaded count()

Re: The new optimized version of Dual-Pivot Quicksort

Hi Tagir! I wrote a simple benchmark comparing Arrays.sort() and your implementation: https://gist.github.com/orionll/595d10ff37ffe0d8c3824e734055cf00 Here are the results on my computer (JDK 11): REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on why

Re: The new optimized version of Dual-Pivot Quicksort

ady > sorted, so in fact you are testing how algorithms behave on already > sorted arrays. > > With best regards, > Tagir Valeev. > On Mon, Nov 12, 2018 at 10:08 AM Zheka Kozlov > wrote: > > > > Hi Tagir! > > > > I wrote a simple benchmark c

Re: Feature suggestion: Add static equals methods to Float and Double

Why don't we just add a generic method which compares any instances of Comparable? public interface Comparator { ... public static > boolean equal(T x, T y) { return x.compareTo(y) == 0; } } Usage: Comparator.equal(1, 1); // true Comparator.equal(1.0, 1.0); // true

Re: Feature suggestion: Add static equals methods to Float and Double

pes which > I initially wanted to prevent. > > > Zheka Kozlov hat am 6. Januar 2019 um 11:56 > geschrieben: > > > > > > Why don't we just add a generic method which compares any instances of > Comparable? > > > > > > public interface Comparator { &

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

OCA. ср, 12 дек. 2018 г. в 11:25, Martin Buchholz : > I used to believe that, but apparently I was wrong. > https://openjdk.markmail.org/thread/rfqfultw35i2az45 > > On Tue, Dec 11, 2018 at 8:14 PM Zheka Kozlov > wrote: > >> Would be better to add @Stable to the fields

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

load of consumed field at > each iteration. See original post by Nitsan Wakart > https://psy-lob-saw.blogspot.com/2014/08/the-volatile-read-suprise.html > > Regards, > Sergey Tsypanov > > > 07.12.2018, 15:22, "Zheka Kozlov" : > > Wha

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

Would be better to add @Stable to the fields instead? (`n` and `element` are final, so @Stable is OK here) ср, 12 дек. 2018 г. в 11:02, Martin Buchholz : > In performance critical code, we don't trust hotspot to not reload final >> fields. Other forEach methods do this, e.g. > > > final

Re: Optimized version of CopiesList.hashCode()

I think we should choose Tagir's version so you don't need my OCA. сб, 1 дек. 2018 г. в 06:38, Stuart Marks : > > > On 11/30/18 8:52 AM, Martin Buchholz wrote: > > On Thu, Nov 29, 2018 at 8:02 PM, Tagir Valeev wrote: > > > >> I can file an issue and create a webrev, but I still need a sponsor >

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

ee the > explanation here: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html > > Ok. I wonder why this message received no attention. > > Here's updated webrev: > http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r3/ > > With best regards, > Tagir Valeev

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

I think you should use iterator() instead of listIterator(). See the explanation here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052472.html вт, 4 дек. 2018 г. в 12:23, Tagir Valeev : > Hello! > > Thank you for your comments! > > Yes, deserialization will be broken if we

Re: Optimized version of CopiesList.hashCode()

> If n == 1, then it would become `mask = n << 32`, and the loop would run 32 times. Forget my implementation. It is incorrect at all. In only works for odd numbers :( пт, 30 нояб. 2018 г. в 13:58, Ivan Gerasimov : > Hi Zheka and Tagir! > > > On 11/29/18 10:37 PM, Zheka Koz

Re: Optimized version of CopiesList.hashCode()

t; winning from n = 10 and after that logarithmic algorithm really rocks. > > I can file an issue and create a webrev, but I still need a sponsor > and review for such change. Martin, can you help with this? > > With best regards, > Tagir Valeev. > On Tue, Nov 27, 2018 at 5:49

Optimized version of CopiesList.hashCode()

Currently, CopiesList.hashCode() is inherited from AbstractList which: - calls hashCode() for each element, - creates a new Iterator every time. However, for Collections.nCopies(): - All elements are the same. So hashCode() can be called only once. - An Iterator is unnecessary. So,

Re: RFR(s): JDK-8214687 Optimize Collections.nCopies().hashCode()

lo! > > > > Please review and sponsor the optimized implementation of > > Collections.nCopies().hashCode(): > > https://bugs.openjdk.java.net/browse/JDK-8214687 > > http://cr.openjdk.java.net/~tvaleev/webrev/8214687/r1/ > > > > Previous discussion thread: > > > http://ma

Re: RFR: 8180352: Add Stream.toList() method

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks wrote: > This change introduces a new terminal operation on Stream. This looks like a > convenience method for Stream.collect(Collectors.toList()) or > Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this > method directly on

Re: RFR: 8180352: Add Stream.toList() method

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks wrote: > This change introduces a new terminal operation on Stream. This looks like a > convenience method for Stream.collect(Collectors.toList()) or > Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this > method directly on

Re: RFR: 8180352: Add Stream.toList() method

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks wrote: > This change introduces a new terminal operation on Stream. This looks like a > convenience method for Stream.collect(Collectors.toList()) or > Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this > method directly on

Package-private members in java.util.ArrayList

Hi! JEP 181 (Nestmates) was implemented in Java 11, however, there are still many library classes with members that were declared package-private to avoid synthetic bridge methods. For example, ArrayList and its friends have the following declarations: • transient Object[] elementData; //

java.io.Serial vs java.io.Serializable javadoc

Hi! The javadoc of java.io.Serial [1] says that serialVersionUID is private. But the javadoc of Serializable [2] says it can have any access modifier. Who is right here? When I write the following code, should there be a warning or not? import java.io.Serial;import java.io.Serializable; public