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

[Roger Riggs]

Looks good.

Thanks for the alternative investigations,  Roger


On 9/11/19 12:58 PM, Brian Burkhalter wrote:
> 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?