Hello,
Please review the changes to address:
JDK-8224012: AnnotatedType implementations of hashCode() lead to
StackOverflowError
http://cr.openjdk.java.net/~darcy/8224012.1/
As discussed in the JBS entry, this is a follow-up issue to fix an
implementation flaw in JDK-8058202:
908>
Job:
mach5-one-jdk-13-1151-tier2-20190528-1515-2755946<http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
Original changset:
http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69<http://hg.openjdk.java.net/jdk/jdk/rev/63ab89cc3e69>
Hi Brent!
On 5/28/19 4:06 PM, Brent Christian wrote:
Hi, Ivan
I agree with Roger that there are more test cases than necessary.
Otherwise I think it looks pretty good.
Okay. Then let's make the list of invalid ranges shorter, but add a
randomly generated value!
Please find the updated
Hi, Ivan
I agree with Roger that there are more test cases than necessary.
Otherwise I think it looks pretty good.
I find the addExact/multiplyExact code less readable. I'm not sure what
could be done about it - maybe some different indentation:
cmin = Math.addExact(
.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908
>>> <https://bugs.openjdk.java.net/browse/JDK-8224908>
>>>
>>> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946
>>> <http://java.se.oracle
Hi Aleksey,
The is always optional (in html5).
The issue with the "when control returns" and "best effort" sentence is
that is implies that something has been done
and that is not necessarily true. At best, it could say is that the
implementation may have done something or done nothing
and
/index.html
<http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
JBS: https://bugs.openjdk.java.net/browse/JDK-8224908
<https://bugs.openjdk.java.net/browse/JDK-8224908>
Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946
<http://java.se.oracle.com:10065/mdash/jobs/mach5-
t;
>> -- Jim
>>
>> Reverse webrev:
>> http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html
>> <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908
>> <https://bugs.openjdk.java
t; <http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908
> <https://bugs.openjdk.java.net/browse/JDK-8224908>
>
> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946
> <http://java.se.oracle.com:10065/
;
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8224908
>> <https://bugs.openjdk.java.net/browse/JDK-8224908>
>>
>> Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946
>> <http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528
://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html
<http://cr.openjdk.java.net/~jlaskey/8224908/webrev/index.html>
JBS: https://bugs.openjdk.java.net/browse/JDK-8224908
<https://bugs.openjdk.java.net/browse/JDK-8224908>
Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946
<http://java.se.o
va.net/browse/JDK-8224908
<https://bugs.openjdk.java.net/browse/JDK-8224908>
Job: mach5-one-jdk-13-1151-tier2-20190528-1515-2755946
<http://java.se.oracle.com:10065/mdash/jobs/mach5-one-jdk-13-1151-tier2-20190528-1515-2755946>
Original changset: http://hg.openjdk.java.net/jdk/jdk/rev/6
I remember looking at this bug back in 2005 and being afraid to touch it.
The size-based algorithm does feel kludgy but it *is* specified, and
changing that is too incompatible - it would have been rejected at that
time.
I have a lot of sympathy for Alan's insistence on keeping the optimization
On 5/28/19 7:58 PM, Roger Riggs wrote:
> Please review a change to the javadoc of Runtime.gc() and System.gc() to
> clarify
> that invoking these methods does not guarantee any specific result or
> timeliness
> of completion.
>
> The revised text is:
>
> * Runs the garbage collector in
Please review a change to the javadoc of Runtime.gc() and System.gc() to
clarify
that invoking these methods does not guarantee any specific result or
timeliness
of completion.
The revised text is:
* Runs the garbage collector in the Java Virtual Machine.
*
* Calling this
Thank you Roger for reviewing!
On 5/28/19 9:33 AM, Roger Riggs wrote:
Hi Ivan,
test/jdk/java/util/regex/RegExTest.java:
4954: The test should print the failing exception information and
4951: a message if the Pattern.compile does not fail to distinguish
that failure from any others.
Yes,
+1
> On May 28, 2019, at 1:42 PM, Joe Darcy wrote:
>
> Hello,
>
> Double-checking the changes, I found a few more instances of "white space" in
> a code markup that I'll change to plain text as part of the fix; several
> edits of
>
> {@link Character#isWhitespace(int) white space
On 5/28/19 10:19 AM, Martin Buchholz wrote:
We could enhance @inheritDoc to make the source clear {@inheritDoc from
Set.removeAll})
Generally, improving {@inheritDoc} is on the list.
-- Jon
On Mon, May 27, 2019 at 1:35 AM Peter Levart wrote:
>
>
> On 5/26/19 6:25 PM, Martin Buchholz wrote:
> > On Mon, May 13, 2019 at 5:29 PM Stuart Marks
> > wrote:
> >
> >>- addition of FIXME comment and reference to javadoc bug report,
> where
> >> doc
> >> comment from interface cannot be
Hello,
Double-checking the changes, I found a few more instances of "white
space" in a code markup that I'll change to plain text as part of the
fix; several edits of
{@link Character#isWhitespace(int) white space characters}
to
{@linkplain Character#isWhitespace(int) white space
On Mon, May 27, 2019 at 8:38 AM Pavel Rappo wrote:
> Would you care to elaborate on that? As far as I understand Stuart was
> simply
> working around javadoc's bug in the "Copying of Method Comments" algorithm.
>
It's not really a javadoc bug. Java doesn't really provide any way to
distinguish
On Mon, May 27, 2019 at 2:07 AM Florian Weimer wrote:
> * Martin Buchholz:
>
> > Very big picture - if we want to banish stack overflows forever, we would
> > need to migrate the industry to split runtime stacks, which would add a
> bit
> > of runtime overhead to every native function call. No
Hi Ivan,
test/jdk/java/util/regex/RegExTest.java:
4954: The test should print the failing exception information and
4951: a message if the Pattern.compile does not fail to distinguish that
failure from any others.
I don't think there is a need for so many cases of values > 2^31; there
is no
Hello!
When the fix for JDK-7039066 (which added support for the flag
UNICODE_CHARACTER_CLASS and corresponding embedded expression (?U)) was
integrated back in JDK 7, the documentation for the non-capturing groups
was not updated accordingly.
Would you please help review the fix, which
On 28/05/2019 16:00, Andrew Dinn wrote:
:
Yes, I'll raise one ASAP. Could you clarify what changes I need to
document in the CSR? Here are my current thoughts:
ManagementFactoryHelper/FileChannelImpl
I am assuming the change that exposes the new MXBean needs to be
mentioned somwehere. However,
Hi Alan,
Thank you for the review.
On 26/05/2019 19:25, Alan Bateman wrote:
> You may want to take a pass over the JEP to make sure that everything is
> accurate. I notice, for example, the section on BufferPoolMXBean has the
> old name READ_ONLY_PERSISTENT. We went through a couple of
It is critical to replicate what the javac compiler is doing presently,
otherwise we break existing code.
char leadch = reader.ch;
int oct = reader.digit(pos, 8);
reader.scanChar();
if ('0' <= reader.ch && reader.ch <= '7') {
oct = oct * 8 + reader.digit(pos, 8);
+1
> On May 28, 2019, at 6:48 AM, Sundararajan Athijegannathan
> wrote:
>
> Updated for java test failures:
>
> https://cr.openjdk.java.net/~sundar/8216553/webrev.01/
>
> PS. Test framework used wrong jrt: URI pattern. Fixed it.
>
> -Sundar
>
> On 27/05/19, 5:37 PM, Alan Bateman wrote:
>>
Updated for java test failures:
https://cr.openjdk.java.net/~sundar/8216553/webrev.01/
PS. Test framework used wrong jrt: URI pattern. Fixed it.
-Sundar
On 27/05/19, 5:37 PM, Alan Bateman wrote:
On 27/05/2019 10:18, Sundararajan Athijegannathan wrote:
Please review.
Bug:
Hi Jim!
I wonder why it was chosen to represent octal values as \[0-3][0-9][0-9]
| \[0-9][0-9] | \[0-9] ?
First, it will allow multiple leading zeroes.
Second, it does not require a leading zero, while, I think, many users
are used to octal numbers starting with a mandatory leading zero.
30 matches
Mail list logo
