8230342: LineNumberReader.getLineNumber() returns inconsistent results after EOF

Brian Burkhalter brian.burkhalter at oracle.com
Wed Sep 11 16:58:04 UTC 2019


Although I rather like [1] it is probably too expensive to use a lambda just to increment the line number. Therefore I am proposing to modify [2] to replace the AtomicBoolean with a boolean[] as in [3].

Thanks,

Brian

[1] http://cr.openjdk.java.net/~bpb/8230342/webrev.01/
[2] http://cr.openjdk.java.net/~bpb/8230342/webrev.00/
[3] http://cr.openjdk.java.net/~bpb/8230342/webrev.02/

> On Sep 10, 2019, at 11:46 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> 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