Request: Remove System.out check from Class.checkInitted()

David Holmes david.holmes at
Thu Dec 19 11:53:18 UTC 2013

On 19/12/2013 9:19 PM, Jeroen Frijters wrote:
> System.out can be null, because System.setOut(null) is legal.

Ah I see. That isn't an initialization issue but a post-initialization 


> Regards,
> Jeroen
>> From: David Holmes [mailto:david.holmes at]
>> Sent: Thursday, December 19, 2013 11:14
>> To: Alan Bateman
>> Cc: Jeroen Frijters; core-libs-dev at
>> Subject: Re: Request: Remove System.out check from Class.checkInitted()
>> On 4/12/2013 7:00 PM, Alan Bateman wrote:
>>> On 04/12/2013 08:24, Jeroen Frijters wrote:
>>>> Hi,
>>>> I'd like to propose to change Class.checkInitted() to check if the VM
>>>> initialization has completed by using sun.misc.VM.isBooted() instead
>>>> of System.out != null.
>>> This should be changed (I can only guess that whoever added this
>>> wasn't aware of VM.isBooted).
>> Not necessarily. The question is, are there any code paths that lead to
>> checkInitted being called after  setOut0(newPrintStream(fdOut,
>> props.getProperty("sun.stdout.encoding"))) but before the call to
>> sun.misc.VM.booted(). If so these would fail under the proposed change.
>> The initialization sequence is fragile and intimately tied to the
>> Hotspot VM - ie the VM initialization process initiates the core class
>> initialization. In a "normal" initialization System is initialized
>> before Class and Class must be initialized before checkInitted can be
>> called, so this doesn't trigger initialization of System.
>> I also don't see how System.out being null can be valid post-
>> initialization state given the call to setOut0(newPrintStream(fdOut,
>> props.getProperty("sun.stdout.encoding")))
>> David
>> -----
>>> -Alan.

More information about the core-libs-dev mailing list