Hello!
When the regex.Matcher matches a supplementary codepoint, it may
inadvertently cross the border of the explicitly specified region
without noticing.
Would you please help review a simple fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230829
WEBREV: http://cr.openjdk.java.net/~
+1, looks good to me.
Best regards,
Joe
On 9/10/19 2:20 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8230136
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8230136/webrev.00/
The fix
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8230136
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8230136/webrev.00/
The fix is to correct the condition of the invalid case, as suggested in
the bug report.
Naoto
Sergey,
While it might be reasonable to improve doclint support with better
checks for serialization,
I think that is better done as a separate task, and not conflated with
Joe's work here.
-- Jon
On 09/10/2019 11:45 AM, Sergey Bylokhov wrote:
Hi, Joe.
Can we as part of this effort improv
Hi Daniel,
Thanks for the idea. It seems a little strange to me though to have the
incrementing being done in a separate method. It feels a little disconnected.
I wrote up an alternative [1] which instead passes a functional interface to
the readLine() in BufferedReader. This eliminates creatin
Hi, Joe.
Can we as part of this effort improve validation of javadocs tags: @serial,
@serialField, etc.
I am sure that we use these tags here and there incorrectly.
BTW probably we should consider all serialized fields/methods/etc, as kind
of public API, and validates it by doclint accordingly.
Andrew,
I'll take it on, but it will have to go through a CSR review and thus will take
some time.
https://bugs.openjdk.java.net/browse/JDK-8230800
Cheers,
-- Jim
> On Sep 6, 2019, at 5:55 AM, Andrew Leonard
> wrote:
>
> Hi,
> Anyone able to review please?
> Thanks
> Andrew
>
> And
Hi Florian
On Mon, 9 Sep 2019 at 15:04, Florian Weimer wrote:
>
> Ahh. The other option is to stick with one server and keep resending
> with larger and larger timeouts. Switching has the advantage that in
> case of a server problem, you get to a working server more quickly.
> Staying means tha
> > On 5 Sep 2019, at 16:02, Pavel Rappo wrote:
> >
> > I think we are almost there. What do you think of the following incremental
> > (i.e. on top of your latest webrev) change?
> >
> >http://cr.openjdk.java.net/~prappo/8228580/webrev.01/
> >
> > I fixed a couple of trivial typos and addres
Here's a canonical example of an "expected timeout" test that seems natural
and readable to me.
timeoutMillis() returns 12ms, adjusted by timeout factor. Ldap might need
a bigger value.
/**
* timed await times out if not counted down before timeout
*/
public void testAwaitTimeo
On Tue, Sep 10, 2019 at 7:25 AM Pavel Rappo wrote:
> > On 6 Sep 2019, at 20:02, Martin Buchholz wrote:
> >
> > Martin's rules for test methods:
> > - never have more than 100 millisecond total expected runtime
> > - never have more than 12 millisecond blocking time for any single
> operation
> >
Hi,
On 09/09/2019 15:35, Roger Riggs wrote:
- Is the use of AtomicBoolean due to concurrency concerns?
If not, a new boolean[1] would be less overhead
Alternatively, BufferedReader could define an empty package
method called e.g.
void endOfLine() { };
that LineNumberReader could overri
Hi,
the subject should mention 8218628. (Not 8218626).
Sorry for this!
Best regards,
Goetz.
From: Lindenmaier, Goetz
Sent: Dienstag, 10. September 2019 11:48
To: 'Hotspot dev runtime' ; Java Core
Libs
Subject: RFR (L, final): 8218626: Add detailed message to NullPointerException
describing
Hi Roger,
> On Sep 10, 2019, at 7:33 AM, Roger Riggs wrote:
>
> Reconsidering...
>
> If the current line number starts at zero and is incremented only by CR/LF
> then my example program is wrong. It called getLineNumber *after* reading
> the line and it should have called it *before*.
After t
Hi Brian,
Reconsidering...
If the current line number starts at zero and is incremented only by CR/LF
then my example program is wrong. It called getLineNumber *after* reading
the line and it should have called it *before*.
So I can support your original patch (modulo not using AtomicBoolean).
> On 6 Sep 2019, at 20:02, Martin Buchholz wrote:
>
> Martin's rules for test methods:
> - never have more than 100 millisecond total expected runtime
> - never have more than 12 millisecond blocking time for any single operation
> - yet be able to survive a one-time 5 second thread suspension at
This looks OK -
I want it integrated before upcoming CLI changes so the test changes for
the CLI changes will be done using the new test helpers.
/Andy
On 9/9/2019 1:14 PM, Alexey Semenyuk wrote:
Please review the jpackage fix for bug [1] at [2].
This is a fix for the JDK-8200758-branch bra
Milan,
ping?
> On 5 Sep 2019, at 16:02, Pavel Rappo wrote:
>
> I think we are almost there. What do you think of the following incremental
> (i.e. on top of your latest webrev) change?
>
>http://cr.openjdk.java.net/~prappo/8228580/webrev.01/
>
> I fixed a couple of trivial typos and addr
Hi,
this is the implementation of JEP 358: Helpful NullPointerExceptions.
The JEP is in status "Candidate". Coleen (many, many thanks!) ran
it through the Oracle-internal processes. Now I please need final reviews
for this change so that I can propose it to target jdk 14.
JEP: https://bugs.open
I am sending this feedback as suggested by the jpackage project
(https://jdk.java.net/jpackage/). I hope this is considered helpful
information.
I have tried the current build "14-jpackage+1-35" on Windows. It pretty
much worked out of the box for me. Here are a few observations I make:
- creat
20 matches
Mail list logo
