Hello Achyuta,
Welcome to the OpenJDK project. Keeping aside the implementation details
of the proposal, changing the format of how the property key/values that
are written out will have wider implications. It would mean that the
existing property files following the older format can no longer be
loaded using the Properties class. Of course, one can imagine enhancing
the load methods to allow this newer format, but that then means
maintaining multiple different formats of how properties are written and
loaded. This class has been around for several decades and it doesn't
feel necessary to introduce this level of complexity in that class.
I haven't given it much thought, but if you do want to introduce a
different way to store (and load) these properties, then one could
always come up with a utility class in the application/library which
takes a Properties instance and stores/loads the key/values from the
Properties in a manner that's more suitable to the application/library.
On a more general note, if your email's content consists of LLM
generated content, please also take a look at the OpenJDK policy on LLM
usage https://openjdk.org/legal/ai (which expects even email messages to
be compliant).
-Jaikiran
On 15/06/26 6:37 am, Achyuta Shrimate wrote:
Hello OpenJDK Core Libraries Team,
I hope this message finds you well. My name is Achyuta Shrimate, and I am
writing to express my interest in contributing to the OpenJDK project,
specifically to the java.util.Properties class.
Problem Statement:
Currently, java.util.Properties.store() serializes values by escaping all
special characters (\n, \t, \\, etc.) into their escaped representations.
This makes the resulting .properties file machine-readable but difficult
for humans to read and edit, particularly for values that contain multiline
content or indentation.
For example, a value containing a newline gets stored as:
Project.Imports=0rg,\n maven,\n eclipse
Whereas a developer would expect to read:
Project.Imports=0rg,\
maven,\
eclipse
OR
Project.Imports=0rg,
maven,
eclipse
Proposed Addition:
I would like to propose the addition of the following public method to
java.util.Properties:
public void storeFormatted(FileWriter fileWriter, String comments)
throws IOException
This method would:
- Mirror the existing store(Writer, String) pattern internally by
delegating to a private storeFormatted0(BufferedWriter, String) method,
consistent with the existing store() → store0() design
- Reuse the existing saveConvert() for key serialization
- Introduce a lightweight restoreEscapes() helper that un-escapes only \\
→ \, \n → newline, and \t → tab in values, leaving all other escape
sequences untouched
- Preserve the existing sorted key output behavior introduced in recent
JDK versions
- Be fully additive with zero changes to existing store() behavior
I am willing to:
- Draft a formal JEP or raise a bug/enhancement on the OpenJDK issue
tracker if the team considers this worthwhile
- Write the full implementation and accompanying JTreg tests
- Iterate on the API design based on community feedback, including which
escape sequences to restore (currently proposing \\, \n, \t as a minimal
baseline)
I would greatly appreciate any guidance on the right process to move this
forward and whether this aligns with the team's current priorities for
java.util.Properties.
Thank you for your time and for maintaining such a foundational part of the
Java ecosystem. I would be filing the Individual OCA and then be will be
ready to contribute on this issue.
Best regards,
*Name:* Achyuta Shrimate
*Github: *ASAnonymousS
*Email: *[email protected]
