Discussion: Efficient ByteBuffer -> String that avoids additional copying

Paul, Would you mind explaining more about what you're looking for regarding this? I'm curious if `ByteBuffer#getString` is what you're after, or rather something similar to `String.from(ByteBuffer)`. I'll definitely have a look at jdk.internal.misc.SharedSecrets in the meantime. Thanks! - Jac

Discussion: Introduce a `Stream.reject` method, the opposite of `Stream.filter`

Seeing as `Predicate.not` was just proposed, I think it would be a good idea to also introduce `Stream.reject`, which would be logically equivalent to calling `Stream.filter` with a negated `Predicate`, but with fewer method calls. Instead of: Stream.of("", "A", "B", "C") .filter(s -

Re: BiCollector

Agreed. Not sure if this has been suggested, but what about duplex(ing)? On Mon, Jun 18, 2018 at 5:29 PM Brian Goetz wrote: > "bisecting" sounds like it sends half the elements to one collector and > half to the other ... > > "tee" might be a candidate, though it doesn't follow the `ing > conve

Stream Method Proposal: long count(Predicate predicate)

em to use IntPredicate, DoublePredicate, and LongPredicate respectively. Thanks, Jacob Glickman

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

this type of convenience method could also be useful for findFirst, in addition to findAny, distinct, etc. Thanks, Jacob Glickman On Thu, Nov 8, 2018 at 4:46 AM Tagir Valeev wrote: > What's wrong with `filter(predicate).count()`? Saving nine characters? > > With best regards, >

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

There was a typo in my last e-mail: `.count("Java::equals")` should be `.count("Java"::equals)` Thanks, Jacob Glickman On Thu, Nov 8, 2018 at 9:02 AM Jacob Glickman wrote: > Tagir, > > Nothing is wrong with it, but I think the addition of the convenience >

Stream Method Proposal: long count(Predicate predicate)

em to use IntPredicate, DoublePredicate, and LongPredicate respectively. Thanks, Jacob Glickman

Mechanism to maintain backwards compatibility when moving classes to different packages

all would think of this, as it is not just applicable to this single example. There have been plenty of times that I've realized that my packages were named badly, but I'm forced to stick with that naming (unless I want my users to have to modify their code). Thanks,

Fwd: Mechanism to maintain backwards compatibility when moving classes to different packages

Friendly reminder :) -- Forwarded message - From: Jacob Glickman Date: Sat, Jun 22, 2019 at 4:42 PM Subject: Mechanism to maintain backwards compatibility when moving classes to different packages To: Yesterday, Mark Reinhold introduced the idea of a java.util.random subpackage

[PATCH] 8202521: Add overloaded methods of Map#compute, Map#computeIfAbsent, Map#computeIfPresent

ava Wed May 02 11:21:27 2018 -0700 +++ b/test/jdk/java/util/Map/Defaults.java Thu May 03 09:52:47 2018 -0700 @@ -25,7 +25,7 @@ * @test * @bug 8010122 8004518 8024331 8024688 * @summary Test Map default methods - * @author Mike Duigou + * @author Mike Duigou, Jacob Glickman *

[PATCH] 8202521: Add overloaded methods of Map#compute, Map#computeIfAbsent, Map#computeIfPresent

Hi Paul, Thank you for the response! I understand I should have discussed this before submitting a patch, and will do so from now on. I would be happy to contribute to fixing some starter bugs, and I'd be very grateful if you are able point me to some! - Jacob