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

[Alan Bateman]

On 25/08/2021 15:57, Jaikiran Pai wrote:
> :
>
> Introducing an overloaded "store" which takes the timestamp or 
> implicitly using the SOURCE_DATE_EPOCH environment variable would mean 
> that the Properties.store(...) APIs will continue to always write out 
> a Date representation into the outputstream. That effectively means 
> that there will continue to be no way to disable writing out a (date) 
> comment. More specifically, even if a user doesn't explicitly specify 
> a comment, we would end up writing a default (date) comment. Do we 
> want that? Or while we are doing these changes, should we introduce 
> this ability of disabling writing out these date comments by default? 
> That, IMO, can only be done by introducing new APIs instead of trying 
> to slightly change the spec and the implementation of the current 
> "store" APIs. After all, if any callers do want a date (and a 
> reproducible one at that), they could always do so by passing that as 
> a value for the "comment" parameter of these (new) "storeXXX" APIs.

Properties save/store has always emitted a comment line with the current 
date/time, it goes back to JDK 1.0. It's unfortunate that newer store 
methods didn't re-examine this, also unfortunate that it continued with 
8859-1. In the discussion on jdk-dev about reproducibility then I think 
we concluded that we don't want to change the behavior of existing 
methods, hence the discussion on introducing a new method.

An new overload of store would give the maximum flexibility to new code 
but it would require programs used in builds to use it consistently. 
It's possible that libraries or tools that are using Properties::store 
have no idea that they will ultimately be used in a system that is 
trying to produce reproducible builds. So I have some sympathy to the 
argument that there should a way to omit the date or emit it as the Unix 
epoch time or a fixed value. This would mean changing the spec to allow 
for some implementation means to do this, and maybe an implNote that 
documents that it reads SOURCE_DATE_EPOCH. I think Roger has misgivings 
about this.

So let's list the options and the pros/cons and see if we can converge 
on an approach.


> I think, based on the discussion/inputs so far, there's clarity on 
> this part that changing the current implementation of "store" to write 
> out the property keys in a specific order would be a good thing, 
> irrespective of whether or not we introduce new APIs to deal with the 
> date comment aspect. Daniel had an interesting point of 
> logging.properties file and the order that would need to be maintained 
> for those, but like he noted in that same reply, I don't think that's 
> a use case to consider for the "store" APIs, since they never 
> previously supported/guaranteed that use case.
Yes, I think we should be okay there. I suspect the iteration order has 
changed once or twice already, e.g. when Properties was re-implemented 
to use a CHM.

-Alan