RFR 8185496: Improve performance of system properties initialization in initPhase1

Mandy Chung mandy.chung at oracle.com
Fri Nov 9 17:15:55 UTC 2018

On 11/9/18 7:25 AM, Roger Riggs wrote:
> Hi Mandy
> On 11/08/2018 04:55 PM, Mandy Chung wrote:
>> On 11/8/18 7:41 AM, Roger Riggs wrote:
>>> Webrev updated in place:  (Only System.java is modified)
>>> http://cr.openjdk.java.net/%7Erriggs/webrev-props-cleanup-8185496/index.html
>> Just notice this...
>> I wonder if System.setProperties(null) should call 
>> VM.saveAndRemoveProperties(props) to be consistent.  It's an existing 
>> issue.  You may consider refactoring and adding initSystemProperties 
>> method that will be called from initPhase1 and setProperties.
> The purpose of VM.savedProperties is to ensure that the initial 
> properties are not mutable.
> The AndRemove is an adhoc way to hide some properties that don't need 
> to be seen by applications.
> Allowing the former set to be changed by setProperties() would break 
> that intention.
> I'm not aware of any problems with the current implementation of 
> (setProperties)
> and so would leave it alone at least for now.
> Further, System.setProperties() should be deprecated (probably for 
> removal) since it
> gives the impression of being able to reset all the properties. But 
> many property values
> are only used for initialization and are read or cached on first use 
> and not read again
> because changing them has no effect or can cause unexpected behaviors.

I agree we should not do more on System.setProperties.   Your patch is 
good to go.

I also support to deprecate System::setProperties while we should 
collect some data
and understand how it is used in existing libraries.


More information about the core-libs-dev mailing list