8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF
Brian Burkhalter
brian.burkhalter at oracle.com
Tue Sep 10 18:46:50 UTC 2019
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 creating an AtomicBoolean and avoids using a boolean[] parameter like a pseudo-pointer.
Thanks,
Brian
[1] http://cr.openjdk.java.net/~bpb/8230342/webrev.01/
> On Sep 10, 2019, at 7:57 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>
> 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 override to increment lineNumber.
>
> So:
>
> 351 if (term != null) term.set(true);
>
> would simply become
>
> 351 endOfLine();
>
> which would be a no-op for BufferedReader but would increment
> lineNumber for LineNumberReader.
>
> Wouldn't that work too?
More information about the core-libs-dev
mailing list