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