Hi David,
I didn't even look at Console.java! I just fixed the double-checked
locking in System.java.
Looking now at Console.cons, that is NOT safely statically initialized:
SharedSecrets.setJavaIOAccess(new JavaIOAccess() {
public Console console() {
if (istty()) {
if (cons == null)
cons = new Console();
return cons;
}
return null;
}
(but it's currently safe because only System.java accesses it)
Now perhaps Console.cons is deserving of its own proper init-once code.
Perhaps we don't need a static Console field in both classes Console and
System?
On Tue, Jul 26, 2016 at 7:31 PM, David Holmes <david.hol...@oracle.com>
wrote:
> On 27/07/2016 6:35 AM, Martin Buchholz wrote:
>
>> Hi Xueming,
>>
>> I'd like you to do a wee code review,
>>
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Console-double-checked-locking/
>>
>
> Humour me - where is the bug? We're simply retrieving the existing Console
> singleton that is safely published through static initialization. All this
> seems to do is improve the performance if a race occurs.
>
> AFAICS the use of locking here isn't necessary at all.
>
> Cheers,
> David
>
>
