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

[Daniel Fuchs]

On Wed, 15 Sep 2021 15:31:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Clarify how overriden Properties#entrySet() method impacts the order of stored properties
>>   - Tests to verify subclasses of Properties
>
> src/java.base/share/classes/java/util/Properties.java line 850:
> 
>> 848:      * the {@code entrySet} method and return a different {@code Set} instance,
>> 849:      * then the property list is written out in the iteration order of
>> 850:      * that returned {@code Set}
> 
> Rewording a bit:
> 
> "The keys and elements are written in the natural sort order of the keys in the `Properties.entrySet` unless `entrySet` is overridden by a subclass to return a different instance."
> 
> "different instance" is a bit hard to implement given that entrySet() returns a new synchronized set each time.
> typo: missing final "."

yes - maybe we could work on the wording. Perhaps:
> The keys and elements are written in the natural sort order of the keys in the Properties.entrySet unless entrySet is overridden by a subclass to return a different set implementation.

> src/java.base/share/classes/java/util/Properties.java line 932:
> 
>> 930:             if (entries instanceof Collections.SynchronizedSet<?> ss
>> 931:                     && ss.c instanceof EntrySet) {
>> 932:                 entries = new ArrayList<>(entries);
> 
> From the description referring to a 'different instance', I expected to see == or != in this test.
> Since Properties.entrySet() always returns a new synchronized set of a new EntrySet,
> specifying that the underlying map is the same instance is more difficult.
> Perhaps either the SynchronizedSet or the EntrySet instance could be cached and compared.
> 
> (typo: missing space after period... ".If yes")

A custom subclass couldn't create an instance of EntrySet directly. Therefore if it wants to reorder the entries, it would have to return a new TreeSet or LinkedHashSet - or some other custom set implementation. If the result of calling entrySet() is an EntrySet wrapped in an UnmodifiableSet it's therefore legitimate to assume that the set hasn't been reordered, and that we can reorder it. Or am I missing something?

-------------

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