RFR JDK-8066709 Make some JDK system properties read only

Roger Riggs Roger.Riggs at Oracle.com
Tue Jun 5 15:01:22 UTC 2018


Hi Lance,

The "unless otherwise specified" part is important so reworeded as:

      * <strong>Changing any standard system property may have 
unpredictable results
      * unless otherwise specified.</strong>

Thanks, Roger

On 6/4/2018 4:39 PM, Lance Andersen wrote:
> Hi Roger,
>
>
>
> In System.java
>
> —————
> <strong>changing any standard system property may have unpredictable 
> effects</strong>.
>
> ————————
>
> Perhaps capitalize ‘changing' and maybe consider ‘results’ vs ‘effects’
>
>
>
> HTH
>
> Best
> Lance
>> On Jun 4, 2018, at 3:55 PM, Roger Riggs <Roger.Riggs at Oracle.com 
>> <mailto:Roger.Riggs at Oracle.com>> wrote:
>>
>> Hi Lance,
>>
>> On 6/4/2018 12:09 PM, Lance Andersen wrote:
>>> Hi Roger,
>>>
>>> Overall, it looks very good.
>>>
>>> A couple of quick thoughts, nothing that needs any action unless you 
>>> feel the desire :-)
>>>
>>> Line 671 in System.java, it mentions ‘standard’ system properties. 
>>>  (as does the existing Implementation note) but it does not really 
>>> specify what a standard system property is (though it can be 
>>> assumed) in getProperties overview.  Not a big deal, just thought I 
>>> would point it out in case you had a alternative thought.
>> Yes, it is a bit vague and the documentation of properties is spread 
>> over many packages and classes.
>> 'Standard' generally refers to any property defined in the scope of 
>> Java SE or the documented JDK properties.
>> (For example, those subject to the CSR process).
>>>
>>> Do you think we should had a mention in getProperty() about this 
>>> cached properties (or do we think the reference to getProperties() 
>>> is enough)
>> Hard to say,  there will be a release note, but the properties 
>> methods are well known and it is
>> likely no one reads the javadoc anymore.  getProperty delegates to 
>> getProperties for most of its behavior.
>>
>> Adding a repeat of the API note to System.setProperties and 
>> System.setProperty might be more to the point,
>> warning against setting standard system properties via the API.
>> I added the apinote to each of the 6 methods for setting, clearing, 
>> or getting properties. If that seems excessive,
>> I'm open to removing it from those that provide the least value.
>>
>> Thanks, Roger
>>
>>>
>>> Best
>>> Lance
>>>> On Jun 4, 2018, at 9:32 AM, Roger Riggs <Roger.Riggs at oracle.com 
>>>> <mailto:Roger.Riggs at oracle.com>> 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/ 
>>>> <http://cr.openjdk.java.net/%7Erriggs/webrev-static-property-8066709/>
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8066709
>>>>
>>>> CSR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8204235
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>
>>> <oracle_sig_logo.gif> 
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



More information about the core-libs-dev mailing list