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
issue.
Thanks,
David
Regards,
Jeroen
From: David Holmes [mailto:david.hol...@oracle.com]
Sent: Thursday, December 19, 2013 11:14
To: Alan Bateman
Cc: Jeroen Frijters; core-libs-dev@openjdk.java.net
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.
