[BUG] java.util.Properties.entrySet() does not override java.lang.Object methods since Java 9

Rob Spoor openjdk at icemanx.nl
Sat May 23 19:22:44 UTC 2020


On 23/05/2020 21:13, Rob Spoor wrote:
> Hi,
> 
> I was working on upgrading a library of mine from Java 8 to 11, and I 
> noticed my unit tests started failing. Some investigation showed that in 
> Java 9, java.util.Properties was rewritten to no longer rely on the fact 
> that it extends Hashtable. One of the changes was to use a private 
> static class called EntrySet. However, while this class implements most 
> methods from java.util.Set, it's actually missing two: equals and 
> hashCode. As a result it does not adhere to the general contract of 
> java.util.Set. It's also missing a toString implementation, thereby 
> inheriting its String representation from java.lang.Object. I've checked 
> the source code up to Java 14, and even the Mercurial repository, and 
> this issue still exists.
> 
> I think this could be solved as simply as by having this private 
> EntrySet class extend AbstractSet, or otherwise delegate its methods to 
> its entrySet field. The latter is probably preferred, as it matches the 
> implementation of the same methods of the java.util.Properties class 
> itself.
> 
> Rob

I've also noticed that keySet() and values() may behave differently if 
you add an entry with the keySet() as key or values() as value. While 
before that would have printed "(this Collection)", it will now cause a 
StackOverflowError because the key set or values collection no longer 
contains itself (which is the keySet() or values() from the backing 
ConcurrentHashMap), but a synchronized wrapper. While this is a rare 
corner case (nobody in their right mind would add anything but Strings 
to a java.util.Properties object), it is probably an unintended side 
effect of the rewrite of java.util.Properties.


More information about the core-libs-dev mailing list