On 15/09/2026 13:46, Rafael Winterhalter wrote:
Hei Alan, thanks for the feedback and the pointer to the past
discussion. The advantage of using Properties is that its contract is
implicit with the object. It is not a problem to work around the
limitations I mentioned, but the current gaps
Hei Alan, thanks for the feedback and the pointer to the past discussion.
The advantage of using Properties is that its contract is implicit
with the object. It is not a problem to work around the limitations I
mentioned, but the current gaps are so small that I still hoped this
could be addressed in the JVM itself.
I agree that JSON might remove some of the need in the future, but as
a simple, hand-editable format, properties still work surprisingly
well, and I expect it to stay around even with a built-in JSON API.
Many frameworks such as Spring also have native support for parsing
configuration properties from these files, so a build tool might
populate such files for assembled applications, for example by
injecting version information and others. This is one scenario where I
found that a build broke reproducibility. As for line separators, the
discussion is similar. Build caches often store input independently of
the hosting OS, and a step that generates a file like this is not
obviously dependent on an OS, so it might be accidentally OS-dependent.
Again, I understand that this is not a priority, but if you ever
consider a minor brush up of a seasoned API, this one, I think, would
bring some benefits.
I only mentioned the possibility of properties in JSON format to mean
that there will likely need to be some API additions in the future,
maybe it's a toJson, maybe something else, but very likely to be a
different API shape to the existing API to store in properties or XML
formats. The JDK will of course need to continue to support the
properties and XML formats.
A storeCanonical (as originally proposed) or some such method to take an
Instant and String comments would be okay and won't conflict with future
direction. My personal view is that make the line separator configurable
should be avoided if possible.
-Alan
