RFR: 8231640: (prop) Canonical property storage [v7]

Roger Riggs rriggs at openjdk.java.net
Fri Sep 17 16:14:46 UTC 2021

On Thu, 9 Sep 2021 18:31:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>>   dummy commit to trigger GitHub actions job to try and reproduce an unexplained failure with the new tests that happened around 24 hours back, this time yesterday (rule out any time/date/timezone specific issues)
> src/java.base/share/classes/java/util/Properties.java line 887:
>> 885:      * If the value set for {@code SOURCE_DATE_EPOCH} cannot be parsed to a {@code long},
>> 886:      * then the current date and time will be written.
>> 887:      *
> Update to refer to the property and add the {@systemProperty ...} javadoc tag so the property is listed in the system property reference.

"different set implementation" as part of the spec may challenge the compatibility test developers to prove or disprove that statement.
The type of an instance is frequently understood to be the "implementation".
The visible type returned from Properties.entrySet() is SynchronizedSet.
Anyone can create one of those.
That statement might mislead a subclass into thinking they can not/must not return a SynchronizedSet if they want the built-in sorting.
I'm thinking that wording it in other term of the subclass might be better:
"...sort order of the keys in the entrySet() unless entrySet() is overridden by a subclass to return a different value than 'super.entrySet'().   "
The existing implementation is fine.


PR: https://git.openjdk.java.net/jdk/pull/5372

More information about the core-libs-dev mailing list