JDK-8224242 : Properties.load fails to throw IAE on malformed unicode in certain circumstances
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.util
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 13
  • Submitted: 2019-05-20
  • Updated: 2019-05-30
  • Resolved: 2019-05-30
Related Reports
CSR :  
Description
Summary
-------

Change loading of properties files with malformed unicode escape sequences to always fail with IllegalArgumentException.
 
Problem
-------

Certain sequences of properties ending with malformed unicode escape sequences can silently and erroneously be parsed to contain residual values from a preceding line in the property file. Fixing this straight forward bug could theoretically cause some property files that were previously parsed successfully (though incorrectly) without throwing an exception to instead throw an exception.

A property file with malformed unicode sequences is specified to throw IllegalArgumentException. This happen correctly most of the time, e.g., when loading a file looking like this:

"key=value\u00ps\n"

But when the malformed unicode codepoint is at the end of a line and there's a preceding line with data that would have been valid had it been on the current line, the unicode codepoint might silently be parsed using the content of the preceding line. For example this properties file:

"key1=foo\u0123\nkey2=bar\u0\n"

Here the value of key2 will be parsed as if it was 'bar\u0123'. According to the specification, this should throw an IllegalArgumentException.

Solution
--------

Fix the bug and always throw an IllegalArgumentException.

Specification
-------------

No specification change. The behavior is changed to adhere more strictly to the specification after bug is fixed.
Comments
Moving to Approved.
30-05-2019

Thank you for the additional information; moving to Provisional again. I agree with the parent issue needed a release note.
28-05-2019

Updated description - shall I Propose or Finalize?
21-05-2019

I've changed this request to go through the two-phase rather than one-phase CSR process since I'd like to see a more detailed description of the malformed input whose behavior would differ before and after the change. I've updated the parent bug to request a release note. Moving to Provisional.
21-05-2019