Proposal: JDK-8231640 - (prop) Canonical property storage

[Roger Riggs]

Hi Jaikiran,

System properties, especially new ones, should be only settable on the 
command line and read once.
It makes them visible to developers and avoids state-full dependencies 
and concurrency issues.

Retiring system properties is quite difficult because there's no way to 
know if they are still being
used or by whom.  The technique using system properties to revert to 
previous behavior has
been used when API changes are unavoidable and the impact on existing 
applications is not known.
It isn't a good solution but does provide a workaround when an issue is 
discovered.

Better to not introduce them in the first place.


The use of SOURCE_DATE_EPOCH as proposed seems better than most, as its 
definition
has a wider scope and longer expected life than most properties.

Since SOURCE_DATE_EPOCH is an environment variable, not a system 
property, it will be
less visible to developers, but is already read-once at first use of any 
environment variable
as per System.getenv().

$.02, Roger


On 8/28/21 12:45 AM, Jaikiran Pai wrote:
> Hello Roger,
>
> On 28/08/21 12:16 am, Roger Riggs wrote:
>> Hi,
>>
>> I'm finding the idea of removing the hardcoded timestamp and adding a 
>> property to restore compatibility
>> strangely attractive.  I don't think we've yet found a case where the 
>> timestamp was needed (but need to keep looking).
>> (Adding a timestamp to the comment by the caller of store() is 
>> already possible)
>>
>> It will reveal where the timestamp is needed (via some kind of 
>> failure, though perhaps not a timely one)
>> and includes a fallback mechanism when needed.
>>
>> It will generally cleanup up the behavior of an old API.
>> The other approaches make new work for developers based on unclear 
>> requirements.
>
> So this is essentially the proposal 1d that I listed in one of my 
> mails, with the added advantage of allowing users to switch back to 
> the old behaviour with a system property setting. I hadn't considered 
> the system property approach to switch to old behaviour in my 
> proposals, so this is a very good input and I personally think the 
> most logical proposals so far. One question that however remains is, 
> how long (how many releases) do we support this new system property? 
> The --illegal-access option (although not a system property) seems to 
> be one such example where after a few releases, that option will no 
> longer be supported and won't play any role. Perhaps this system 
> property too will follow a similar lifetime?
>
> One other thing - I believe this new system property must be "set once 
> at launch time" kind of property, whose value can be set at launch 
> time and cannot be changed dynamically in the runtime. That would 
> provide consistency in how the Properties class behaves globally 
> within that runtime, instead of potentially behaving differently in 
> different parts of the code, depending on how the callers set/reset 
> the system property value before calling the "store(...)" APIs.
>
> -Jaikiran
>
>