RFR JDK-8066709 Make some JDK system properties read only

Roger Riggs Roger.Riggs at Oracle.com
Wed Jun 6 15:31:34 UTC 2018


Thanks Jason,  1/2 a fix is not enough.

Thanks, Roger

p.s. I don't think the comments and suggestions are all in yet.

On 6/6/2018 10:34 AM, Jason Mehrens wrote:
> Roger,
>
> Looks like StaticProperty.initProperty is never called.  I assume that was suppose to be called on lines 40-43?
>
> Jason
> ________________________________________
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Roger Riggs <Roger.Riggs at Oracle.com>
> Sent: Tuesday, June 5, 2018 9:18 AM
> To: Stuart Marks
> Cc: Core-Libs-Dev
> Subject: Re: RFR JDK-8066709 Make some JDK system properties read only
>
> Hi Stuart,
>
> On 6/4/2018 9:52 PM, Stuart Marks wrote:
>>
>> On 6/4/18 6:32 AM, Roger Riggs wrote:
>>> Please review a change to make the values of java.home, user.home,
>>> user.dir, and user.name
>>> effectively read-only for internal use.  The values are cached during
>>> initialization and the
>>> cached values are used.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-static-property-8066709/
>>>
>>> Issue:
>>>     https://bugs.openjdk.java.net/browse/JDK-8066709
>>>
>>> CSR:
>>>     https://bugs.openjdk.java.net/browse/JDK-8204235
>> Hi Roger,
>>
>> Overall I think the intent of the change is a good one, as is the
>> reimplementation of internal uses of system properties to use an
>> internal API instead.
>>
>> I think it would be good to have an explicit initialization of the
>> SystemProperty class (or whatever it ends up being called) instead of
>> implicitly initializing via a static initializer. If the class is
>> initialized too early, for some reason, things would go wrong.
>>
> That would be a no-op;  I want the values of the properties to be final
> statics which means they have to
> be initialized by the static initializer.
>> Should there be an error, a warning, or assertion checking to make
>> sure that none of the cached values are null? They should all be
>> non-null, right?
> Yes, null will be a fatal InternalError.
>
> Thanks, Roger
>
>> s'marks



More information about the core-libs-dev mailing list