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