codejive/java-properties

A simple Java Properties parser that retains the exact format of the input file, including any comments

java-properties's Issues

The work is not correct if the newline character is \r+\n in properties file.

The work is not correct if the newline character is \r+\n in properties file.

Can you accept my pull request?

Hello, I am using your library in my project https://github.com/wilinz/i18n-translator, first of all thank you very much,
I found some problems during use, as follows,

1. In the store method, write did not call flush() in time, resulting in no real-time output.
2. The hex length of unicode escape may not have 4 bits, resulting in wrong output, such as Arabic.
3. From JDK9 and above, java already supports utf8 properties file, so I add several store methods, which add the option of encoding unicode or not.

I have fixed and tested these problems, but I changed too much and used the gradle build tool instead of maven, so I want to ask if you can accept my pull request,
This library does not use kotlin, but build.gradle.kts uses kotlin, so github will show that 1% of kotlin is used.

OOM caused when correct delimiter is missing

This is not a correct application and is a problem caused by human error. When a line in the properties file lacks the correct delimiter, a java.lang.OutOfMemoryError is caused.

example code:

//String content = "key=A-string-that-lacks-the-correct-delimiter"; //correct
String content = "A-string-that-lacks-the-correct-delimiter"; //The string that caused oom
Reader r = new StringReader(content);

Properties p = new Properties();
p.load(r);

System.out.println(p.get("key"));

Handle UTF8 by default

The java.util.Properties class seems to handle UTF8 just fine by default (even in Java 8), so we should mirror that behaviour instead of creating escape sequences.

Consecutive comment lines with different markers are treated as same block

The javadoc of Properties.findPropertyCommentLines(Cursor pos) states:

Returns a list of token indices pointing to all the comment lines in a comment block. A list
of comments is considered a block when they are consecutive lines, without any empty lines in
between, using the same comment symbol (so they are either all `!` comments or all `#` ones).

However, when running the below test, this proves not to be true:

  @Test
  void testCommentsOfDifferentTypesAreNotSameBlock() throws IOException {
      List<String> expectedComments = new ArrayList<>();
      expectedComments.add("# Bonjour");
      expectedComments.add("# Gruß");

      Properties props = new Properties();
      props.load(new StringReader("! Hi\n! Hello\n # Bonjour\n# Gruß\nfoo=bar\n"));

      List<String> comments = props.getComment("foo");
      assertThat(comments).isEqualTo(expectedComments);
  }

`Properties#store(OutputStream)` doesn't flush the output to the `OutputStream`

The following test fails:

    @Test
    void testStoreOutputStream() throws IOException, URISyntaxException {
        Path f = getResource("/test.properties");
        Properties p = Properties.loadProperties(f);
        ByteArrayOutputStream os = new ByteArrayOutputStream();
        p.store(os);
        assertThat(os.toString()).isEqualTo(readAll(f));
    }

Probably the OutputStreamWriter isn't flushing to the underlying OutputStream?

Hex encoding fails to generate leading zeros

p.setProperty("test","الألبانية");
p.store(System.out);

Expected output: test=\u0627\u0644\u0623\u0644\u0628\u0627\u0646\u064a\u0629
Actual output: test=\u627\u644\u623\u644\u628\u627\u646\u64a\u629

Necessary code being used in asserts

Using required code inside an assert is of course very stupid: it means that the code will very likely not be executed in production code leading to all kinds of problems.