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

[Jaikiran Pai]

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