Specification of Properties.load() does not define behaviour in case of duplicate keys

[Patrick Reinhart]

I see the the problematic there. At least we should clarify the actual
behavior within the load() method specification stating the current 
state.

Having done this the question would be what could be an appropriate 
method
name/signature for the new behavior?

loadUnique()
loadDistinct()

or something like:

@FunctionalInterface
interface EntryRemappingFunction {
   Object merge(Object key, String oldValue, String newValue);
}

load(Reader reader, EntryRemappingFunction remappingFunction)

load(InputStream inStream, EntryRemappingFunction remappingFunction)


where the remappingFunction is used to handle existing values. So the 
existing methods could
be rewired internally to those methods.

Note that the functional interface is just for demonstrating the idea...


-Patrick


> Changing long standing behavior when properties files have duplicate
> keys could be problematic, esp. if there are properties files are
> bundled with a library that is deployed with different JDK releases.
> There was another discussion here recently about storing properties in
> canonical form, JDK-8231640 [1] was created to look into that. I only
> mention because there is other "projects" in this area if you want to
> look into that too.
> 
> -Alan
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8231640