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) Math.ceil(expec
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
>
> 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 fac
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 tac
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: https://git.openjd
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: sumWit
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:
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:
>
>
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: ht
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 GMT+01
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 :
> Updated webrev, bas
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
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 can discover such
> "b
> 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 uniformity.)
>
> -Doug
>
Ah,
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 would be a shame not t
>
> 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 flatMapper function
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 sta
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 = Optional.empty();
Func
#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 fa
2016-09-07 1:22 GMT+02:00 Paul Sandoz :
>
>> On 3 Sep 2016, at 15:06, Stefan Zobel wrote:
>>
>> Hi Paul,
>>
>> there's a small copy & paste error in the code samples in
>> Double/Int/LongStream#iterate()
>>
>> Example DoubleStrea
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
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 2000 is greater tha
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 varianc
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 updated webrev:
>
> http:/
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:
a
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 new
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 do
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
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, I find the wildcard-ridden signature
of
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 less general than th
> 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 issue (fix
>> flatMap keys only, but not affe
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();
> int[] result = IntStream
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)
>
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 sound type-wise.
There's a sim
a **Java** type perspective ".
Regards,
Stefan
>
> On Nov 1, 2015 7:31 AM, "Stefan Zobel" wrote:
>>
>> 2015-11-01 1:12 GMT+01:00 Michael Nascimento :
>> > Hi Vitaly,
>> >
>> > Exactly, I was just trying to point out the method signa
s would require Supplier>, not Supplier> Optional>.
>>
>> sent from my phone
>>
>> On Oct 31, 2015 2:49 PM, "Michael Nascimento" wrote:
>>>
>>> If this instance is an Optional , passing an
>>> Optional will fail to co
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 final anyway. Can you explain?
T
>
> “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 name
ction with the value,
* otherwise doES nothing.
Stefan
2015-09-29 9:39 GMT+02:00 Paul Sandoz :
>
> > On 28 Sep 2015, at 19:45, Stefan Zobel wrote:
> >
> > Hi Paul,
> >
> > is it a good idea to add the "{@inheritDoc}" to the toString() Javadoc of
>
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 :
>
>
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
http://mail.openjdk.
Hi Paul,
looks good.
Stefan
2015-07-30 18:32 GMT+02:00 Paul Sandoz :
> Hi Stefan, Tagir,
>
> Updated:
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8130828-stream-doc-typos/webrev/
>
> Paul.
>
>
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
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 tryAdvan
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 c
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 :
> On Jun 3, 2015, at 6:18 PM, Alan Bateman wrote:
>
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 &&
spliterator.tryAdvance(nodeBui
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++) {
a[i
48 matches
Mail list logo
