Hi,
> Cannot is apparently preferable in English.
OK, changed.
Best regards,
Goetz.
> -Original Message-
> From: coleen.phillim...@oracle.com
> Sent: Mittwoch, 8. Mai 2019 17:32
> To: Lindenmaier, Goetz ; Schmelter, Ralf
> ; Java Core Libs ;
> hotspot-runtime-...@openjdk.java.net;
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060068.html
Thanks for sharing this thread.
I saw Pavel's comments: "I believe it should be incremented on an attempt to
modify the collection, rather than on the effective result of that attempt"
It can be true for bulk modifica
Hello,
Please help to review this patch for migrating RuleBasedCollatorTest
from Tong to Jtreg.
Bug: https://bugs.openjdk.java.net/browse/JDK-8222969
webrev: http://cr.openjdk.java.net/~yzhou/8222969/webrev.03/
Thanks,
Daisy
Hello!
Jdk has several places with similar logic: an array needs to be
reallocated (by at least some defined amount), taking into account the
maximum allowed size of arrays.
There's clearly an opportunity for refactoring, so it is proposed to
introduce a dedicated utility method for calcula
On 5/7/19 4:33 PM, Brent Christian wrote:
Collection.java:
110 * that use different membership semantics. For operations that involve
more than
111 * one collection, it is specified which collection's membership semantics
are
112 * used by the operation.
addAll() and copyOf() inv
On 5/8/19 7:44 AM, Pavel Rappo wrote:
We will certainly hear from Stuart on this very soon.
Heh.
On 5/8/19 5:55 AM, Сергей Цыпанов wrote:
javadoc for AbstractList.modCount is described as
The number of times this list has been structurally modified.
Structural modifications are those tha
On 5/4/19 12:21 AM, Patrick Zhang OS wrote:
Thank you very much for the detailed explanation and examples, which solved most of my
previous questions and confusion. Really appreciate that. I agree with the opinion about
"effort vs benefit".
Re-thought my original tests concerning CMEs that
On 5/7/19 8:21 AM, Pavel Rappo wrote:
That looks good.
A tiny note on your FIXME comment [1]:
68 // FIXME: the first paragraph below is copied from Set.equals, because
69 // {@inheritDoc} will include text from Object.equals.
You might want to check if it is the same as [2] or
On 5/3/19 6:20 AM, Tagir Valeev wrote:
I'm not a Reviewer, but strongly support this change. Simpler is better. Thanks!
[capitalization adjusted]
Hi Tagir,
Thanks for looking at this! I appreciate the review.
As an aside for other readers, there's no requirement that one be a (capital-R)
Hi Joe,
Sorry for the delay. The patch looks good.
Best
Lance
> On Apr 29, 2019, at 6:03 PM, Joe Wang wrote:
>
> Please review an update on the Validation implementation. All XML tests and
> JCK passed.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8222991
> webrevs: http://cr.openjdk.j
On 5/7/2019 4:39 PM, Roger Riggs wrote:
Hi,
Additional comments/observations on the jpackage webrev.
Cleanup opportunities for more maintainable code.
When using the ToolProvider API in an application that has a security
manager,
what permissions must be available? Properties, files, ...
Hi Naoto,
The changes look fine.
Thanks, Roger
On 05/07/2019 04:12 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8221432
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8221432/webrev.0
Hi Naoto,
The comment in
http://cr.openjdk.java.net/~naoto/8221432/webrev.02/make/jdk/src/classes/build/tools/cldrconverter/Bundle.java.udiff.html
"fix up 'Reiwa' era, which can be missing in some locales” seems to imply that
fallback resolution isn’t working properly, because that data (R) is
On 5/7/19 9:36 AM, Lindenmaier, Goetz wrote:
Hi,
Please have a look at this further improved webrev:
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09/
http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/09-incremental/
Harold, Coleen, thanks for pointing me to those methods.
Hi,
yet another String concat startup/footprint optimization.
As the subject implies, we could fold the initialLengthCoder it into the
final mixer. This way we end up with one less bound argument into the
larger method handle combinator tree, with fewer species classes and
lambda forms generated
We will certainly hear from Stuart on this very soon. Meanwhile, I have to say
that the situation you've described is not that clear-cut in my opinion.
I understand there might be a discrepancy between how the `modCount` field is
described and how it is actually used.
Incrementing `modCount` unco
Thanks Misha!
Could I get a “Review” from someone in core libs, please?
Bob.
> On May 7, 2019, at 8:49 PM, mikhailo.seledt...@oracle.com wrote:
>
> Changes look good to me,
>
> Misha
>
>
> On 5/7/19 5:56 AM, Bob Vandette wrote:
>> Please review this change to the Container Metrics implementa
Hello,
javadoc for AbstractList.modCount is described as
> The number of times this list has been structurally modified.
> Structural modifications are those that change the size of the
> list, or otherwise perturb it in such a fashion that iterations in
> progress may yield incorrect results.
Good job. :)
On to the next bug! Hehe.
Best Regards
Adam Farley
IBM Runtimes
Martin Buchholz wrote on 07/05/2019 19:46:26:
> From: Martin Buchholz
> To: Adam Farley8
> Cc: Java Core Libs
> Date: 07/05/2019 19:46
> Subject: Re: RFR: JDK-8222930: ConcurrentSkipListMapTest.clone()
> broken
Hi,
please review a small change that I'd like to see in OpenJDK to get rid of
compilation errors in the Eclipse IDE.
It seems the root cause for the compilation errors is that javac would
sometimes widen capture variables and is hence able to compile the places that
I touch here. The EC4J com
20 matches
Mail list logo
