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
