> I don't recall the issue of the line separator coming up in previous > discussions. The "reproducible builds" topic usually means same source > code and build environment so it might be a stretch to expect builds on > different platforms to produce identical bits.
For what it's worth, when the Gradle team tackled "reproducible builds" it was understood that reproducibility was independent of operating system (hence the need to standardize on a specific set of file permissions and file order within JARs, regardless of the OS default): https://github.com/gradle/gradle/issues/28806 Take care, Daniel On Wed, Sep 16, 2026 at 5:59 AM Alan Bateman <[email protected]> wrote: > 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
