Re: RFR: 8281631: HashMap.putAll can cause redundant space waste

On Thu, 10 Feb 2022 18:09:19 GMT, XenoAmess wrote: > I investigated most of the usages. They just give a size, and get a capacity, > even not change the 0.75 So maybe we can use some int calculation to replace > the 0.75, thus replace Math.ceil for such situations. FWIW, `(int)

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v42]

On Mon, 5 Apr 2021 14:20:56 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can be

Re: better random numbers

> > On this blog entry (year 2017), Lemire is not giving any technical or > scientific argument in favor or against PCG. > > He also refers to, and quotes from, a blog entry (year 2015) of an > influential researcher (whose work he respects) suggesting the entry has > harsh words about PCG. The

Re: RFR: 8214761: Bug in parallel Kahan summation implementation

On Fri, 2 Jul 2021 20:30:24 GMT, Andrew Haley wrote: > Crikey, how did we get that wrong? > It'd be nice if we had a regression test for this. Can you provide one, > please? I found this: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057239.html Ivan Gerasimov already

Re: RFR: 8214761: Bug in parallel Kahan summation implementation

On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves wrote: > 8214761: Bug in parallel Kahan summation implementation What about `Collectors.computeFinalSum()` - should this be `double tmp = summands[0] + summands[1];` or `double tmp = summands[0] - summands[1];` ? - PR:

Re: RFR: 8214761: Bug in parallel Kahan summation implementation

On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves wrote: > 8214761: Bug in parallel Kahan summation implementation src/java.base/share/classes/java/util/DoubleSummaryStatistics.java line 161: > 159: > 160: //Negating this value because low-order bits are in negated form > 161:

Re: RFR: JDK-8261422: Adjust problematic String.format calls in jdk/internal/util/Preconditions.java outOfBoundsMessage

On Tue, 9 Feb 2021 15:47:39 GMT, Matthias Baesken wrote: >> src/java.base/share/classes/jdk/internal/util/Preconditions.java line 212: >> >>> 210: args.get(0), args.get(1), >>> args.get(2)); >>> 211: case "checkFromIndexSize": >>> 212:

Re: RFR: 8247373: ArraysSupport.newLength doc, test, and exception message

On Fri, 4 Dec 2020 06:50:14 GMT, Stuart Marks wrote: > This rewrites the doc of ArraysSupport.newLength, adds detail to the > exception message, and adds a test. In addition to some renaming and a bit of > refactoring of the actual code, I also made two changes of substance to the > code: >

Re: RFR: 8235730: Incorrect javadoc in MatchKind

FWIW, I believe this bug is duplicate of https://bugs.openjdk.java.net/browse/JDK-8213238 Regards, Stefan Am Mi., 11. Dez. 2019 um 17:07 Uhr schrieb Arthur Eubanks : > > Hi, could I get a review for a trivial and tiny doc fix? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8235730 > Webrev:

Re: RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism

In CustomFJPoolTest#testCustomPools() >>assertEquals(splitsForPC, splitsForPHalfC * 2); I'm sure I'm slow on the uptake, but isn't this bound to fail for every commonParallelism == 2^n + 1 in the closed range [2, 127], i.e., for 3, 5, 9, 17, 33, 65? Regards, Stefan 2017-11-08 22:01

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Hi Stuart, only a minor nit. In Map.java, the class-level Javadoc anchor id="immutable" doesn't match the href="#unmodifiable" used in the methods. + * Unmodifiable Maps vs. + * See Unmodifiable Maps for details. Regards, Stefan 2017-11-01 0:49 GMT+01:00 Stuart Marks

Re: RFR: jsr166 jdk9 integration wave 14

Hi Martin, minor thing in CopyOnWriteArrayListTest.java, line 57 55 public static Test suite() { 56 class Implementation implements CollectionImplementation { 57 public Class klazz() { return ArrayList.class; } Shouldn't this be CopyOnWriteArrayList.class? Regards, Stefan

Re: RFR: jsr166 jdk9 integration wave 13

2016-12-16 20:58 GMT+01:00 Martin Buchholz : > Thanks, Stefan! > > The creation of these bridge classes seem like a misfeature/bug of javac. > We should avoid them where possible. Every unnecessary class file makes > every single java program a little slower to start up. We

Re: RFR: jsr166 jdk9 integration wave 13

> 2016-12-15 18:35 GMT+01:00 Doug Lea : > > Thanks. Changed. > Using s1 on that line wasn't wrong, but wasn't intentional. > (The first use of s1 catches error-before-subscribe; the > "s2" cases just check against side effects, but they should > use s2 consistently for

Re: RFR: jsr166 jdk9 integration wave 13

SubmissionPublisherTest, line 420: "s1.awaitSubscribe();" I might be wrong, shouldn't this be "s2.awaitSubscribe();"? Regards, Stefan 2016-12-14 0:13 GMT+01:00 Martin Buchholz : > We were supposed to be winding down jdk9, and there are a lot of changes > here, but ... it

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

> > Turns out that Rémi's example exposes the difference between the wildcard > approach and the type-parameter approach. Returning to the example, > > Optional oi = Optional.empty(); > Function fm = n -> Optional.empty(); > Optional ocs = oi.flatMap(fm); > > If the

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

Hi Stuart, thanks for explaining. > ... After having looked at lots of generic APIs, it seems to me that a > style has emerged where wildcards are used whenever possible, and type > parameters are used only when necessary, ... Yes, I'm familiar with that kind of reasoning (I think Josh Bloch

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

2016-10-07 21:42 GMT+02:00 Michael Nascimento : > Doesn't work, as Stuart has noted (s'marks, as far as I know your > explanation is 100% correct). Nested generics == pain :-( Hi Michael, sorry for being obtrusive. What exactly doesn't work? Stuart's example Optional oi =

Re: RFR(s): 8152617 add missing wildcards to Optional or() and flatMap()

> > #3flatMap(Function> mapper) > > But this doesn't work for reasons I explain below. Finally, I'm proposing: > > #4flatMap(Function> mapper) > > In researching old email threads and chasing links, I ran across an example > from Stefan Zobel [2] that fails w

Re: RFR 8164691 Stream specification clarifications for iterate and collect

2016-09-07 1:22 GMT+02:00 Paul Sandoz <paul.san...@oracle.com>: > >> On 3 Sep 2016, at 15:06, Stefan Zobel <splitera...@gmail.com> wrote: >> >> Hi Paul, >> >> there's a small copy & paste error in the code samples in >> Double/Int/

Re: RFR 8164691 Stream specification clarifications for iterate and collect

Hi Paul, there's a small copy & paste error in the code samples in Double/Int/LongStream#iterate() Example DoubleStream#iterate: * {@code * for (T index=seed; hasNext.test(index); index = next.apply(index)) { * ... * } * } That should be * for

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

2016-04-18 14:01 GMT+02:00 Tagir F. Valeev : > Hello! > > It was just a quick test not in the clean environment, so you should > not draw any conclusions from the error numbers. It's quite expected > that for limit = 2000 the performance is the same as I have 4 CPU > machine and

Re: RFR: 8154387 - Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less

Hi Tagir, nice catch. I think this optimization is worthwile. I'm a bit surprised about the JMH results for limits 200 and 2000. limit = 200 is significantly faster than the unpatched code (with higher variance, though) and limit = 2000 is about the same, but with a significantly reduced

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hi Tagir, thanks! Looks fine to me now - especially the new testSortDistinct() methods. But note: I'm only a participant, not a reviewer of any sort. Thanks, Stefan 2016-04-12 18:37 GMT+02:00 Tagir F. Valeev : > Hello! > > Thank you, Stefan and Paul for review. Here's

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hi Tagir, another minor issue. The testFlags() methods in IntPrimitiveOpsTests / LongPrimitiveOpsTests each have a duplicated assert: IntPrimitiveOpsTests: assertFalse(IntStreams.of(1, 10).boxed().spliterator() .hasCharacteristics(Spliterator.SORTED)); LongPrimitiveOpsTests:

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hi Tagir, a few comments below a) IntPipeline: public final mapToObj(IntFunction mapper, int opFlags) should be private, not public b) IntPipeline: asDoubleStream() - as already discussed, 0 should be passed as the opFlags value to the DoublePipeline.StatelessOp constructor c) I think, the

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

Hi Tagir, good catch! I like the proposal. > > (different longs can be converted into the same double, so DISTINCT is > not preserved here; not sure whether this is possible for ints) > I think IntStream.asDoubleStream() can also preserve DISTINCT as different ints can't be mapped to the same

CollectionAndMapModifyStreamTest: minor copy-paste error

Hi all, just noticed that org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest has a small copy & paste error in line 116: 115: maps.put(HashMap.class.getName(), () -> new HashMap<>(content)); 116: maps.put(HashMap.class.getName(), () -> new LinkedHashMap<>(content)); The same

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

2016-02-15 7:48 GMT+01:00 Peter Levart : > > > What about even more permissive: > > static Stream iterate3(S seed, Predicate > predicate, Function f) > Hi Peter, yes, Function instead of UnaryOperator is indeed tempting. On the other hand, for my taste,

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

Hi Tagir, this looks good. I wonder, however, if the signature should accept a wider range of types, i.e., something like static Stream iterate(S seed, Predicate predicate, UnaryOperator f) I know that the corresponding static Stream iterate(T seed, UnaryOperator f) is

Re: RFR-8148838: Stream.flatMap(...).spliterator() cannot properly split after tryAdvance()

> 2016-02-08 15:05 GMT+01:00 Paul Sandoz : > >> On 8 Feb 2016, at 14:53, Tagir F. Valeev wrote: >> >> PS> Why don’t you check if "buffer == null” at #189? i.e. similar to >> forEachRemaining: >> >> That would make minimal behavioral change to fix this

Re: Stream.limit parallel ordered performance

2016-01-24 12:36 GMT+01:00 Tagir F. Valeev : > Hello! > > I'm investigating Stream.limit() performance for parallel ordered > streams when no SUBSIZED optimization is performed. > > Consider the following code, for example: > > AtomicInteger counter = new AtomicInteger(); >

Re: RFR 8144675: Add a filtering collector

Hi shinyafox, minor typo in the code example: s/wellPaidEmployeesByDeparetment/wellPaidEmployeesByDepartment Regards, Stefan 2015-12-08 13:04 GMT+01:00 ShinyaYoshida : > Thank you so much! > I've updated in webrev.02. > > Best regard, > shinyafox(Shinya Yoshida) >

Re: Optional.or() doesn't use a wildcard in its signature

t; If this instance is an Optional , passing an >>> Optional will fail to compile. >>> >>> Regards, >>> Michael >>> On 31 Oct 2015 11:21, "Stefan Zobel" <splitera...@gmail.com> wrote: >>> >>> > 2015-10-31 19:11 GMT+01:00 Re

Re: Optional.or() doesn't use a wildcard in its signature

"... from a **Java** type perspective ". Regards, Stefan > > On Nov 1, 2015 7:31 AM, "Stefan Zobel" <splitera...@gmail.com> wrote: >> >> 2015-11-01 1:12 GMT+01:00 Michael Nascimento <mist...@gmail.com>: >> > Hi Vitaly, >> &g

Re: Optional.or() doesn't use a wildcard in its signature

2015-11-01 1:12 GMT+01:00 Michael Nascimento : > Hi Vitaly, > > Exactly, I was just trying to point out the method signature seems broken > anyway. > Rethinking it, I believe you are right. public Optional or(Supplier supplier) would be more general and still be

Re: Optional.or() doesn't use a wildcard in its signature

2015-10-31 19:11 GMT+01:00 Remi Forax : > Hi all, hi Paul, > > I've just seen that Optional.or is declared as > public Optional or(Supplier supplier) { > instead of > public Optional or(Supplier> supplier) { > > regards, > Rémi > I don't get it. Optional is

Re: Optional.or name Re: RFR 8080418 Add Optional.or()

> > “Optional.or” is the best name so far i have come up with. The “orElse” > prefix is reversed for terminal methods and i don’t want to overload that. > > -- > > Alternative suggestions: > > - “Optional.otherwise” > A bit of a mouthful, but reasonably accurate > > - “Optional.mapElse" > The

Re: RFR 8080418 Add Optional.or()

ven action with the value, * otherwise doES nothing. Stefan 2015-09-29 9:39 GMT+02:00 Paul Sandoz <paul.san...@oracle.com>: > > > On 28 Sep 2015, at 19:45, Stefan Zobel <splitera...@gmail.com> wrote: > > > > Hi Paul, > > > > is it a good idea to add the &q

Re: RFR 8080418 Add Optional.or()

Hi Paul, is it a good idea to add the "{@inheritDoc}" to the toString() Javadoc of Optional (and to retain it in OptionalDouble/Int/Long)? As Stuart Marks has observed in the Double/Int/LongSummaryStatistics case the inherited Object.toString() doc is "mostly irrelevant" (see

Re: RFR 8080418 Add Optional.or()

In the OptionalDouble/Int/Long Javadoc of method "empty()" * {@code Optional.empty()}. There is no guarantee that it is a singleton. should be * {@code OptionalDouble.empty()}. There is no guarantee that it is a singleton. and so on. Stefan 2015-09-28 11:24 GMT+02:00 Paul Sandoz

Re: RFR Collector.finisher refers to IDENTITY_TRANSFORM rather than INDENTITY_FINISH

Hi Paul, perhaps you could take the opportunity and also add the missing @since 1.9 tags to all the new dropWhile() / takeWhile() methods (JDK-8071597). Also in dropWhile() / takeWhile() there is a small typo (I guess) in the Javadoc: takeWhile: takes all elements (the result is the same is

Re: RFR 8130828: Fix some typos and omissions in the the j.u.stream JavaDoc

Hi Paul, looks good. Stefan 2015-07-30 18:32 GMT+02:00 Paul Sandoz paul.san...@oracle.com: Hi Stefan, Tagir, Updated: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/ Paul.

Typo in AbstractSpliterator Javadoc

Hi all, I just noticed some typos in the Spliterators.Abstract(Double/Int/Long)Spliterator Javadoc: a) The forEachRemaining link label is forEach instead of forEachRemaining in all AbstractSpliterators. b) The primitive AbstractSpliterators Javadoc has a surplus } just before the tryAdvance

Re: RFR 8071597 Add Stream dropWhile and takeWhile operations

I'm still trying to wrap my head around the test logic for the (par !ord) (op == WhileOp.Drop) case in the whileResultAsserter() method in WhileOpTest. Wouldn't it be possible that, for an unordered parallel stream, dropWhile() won't drop anything at all (i.e., drops an empty set)? In that

Re: RFR 8072773 (fs) Files.lines needs a better splitting implementation for stream source

With respect to the 'stream test library not closing streams' bug: would you mind to create a separate bugtracker issue for that, or do you think it's too special to carry that weight? Thanks, Stefan 2015-06-04 22:06 GMT+02:00 Paul Sandoz paul.san...@oracle.com: On Jun 3, 2015, at 6:18 PM,

Fwd: RFR 8071597 Add Stream dropWhile and takeWhile operations

Hi Paul, Looks good. I was wondering why the truncate method in Node.OfInt / OfLong / OfDouble did not receive the same +if (to == count()) { +spliterator.forEachRemaining(nodeBuilder); +} else { +for (int i = 0; i size

DualPivotQuicksort webrev for JDK-8080945

Hi all, Unless I'm doing something immensely stupid, the DualPivotQuicksort proposal in http://cr.openjdk.java.net/~psandoz/tmp/gs/sort/webrev.2/ doesn't work for me. This little program public static void main(String[] args) { int[] a = new int[287]; for (int i = 0; i a.length; i++) {