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
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
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
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
> 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
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).
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,
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,
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
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
> >
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
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
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, 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.
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
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
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
+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!
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/~
20 matches
Mail list logo
