• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • DSO:L1
  • teck
  • Reporter: teck
  • March 22, 2007
  • 0
  • Watchers: 1
  • September 06, 2013
  • September 06, 2013


Before 2.3 (specifically the changes for EnumMap and EnumSet), a user with a type which subclasses either java.util.AbstractMap or java.util.AbstractSet would not be able to share their type. Before the changes, there were rules that said AbstractMap and AbstractSet were only ADAPTABLE (ie. can take locks, contain roots, etc – but never PORTABLE).

Problem is that someone can effectively get a bunch of Map and Set implementations to be portable even though they have little chance of functioning properly in the cluster (they need logical treatment).

It doesn’t make thing fool proof by any means, but we could disallow these types (ie. AbstractMap/AbstractSet subclasses) with exceptions for the ones we know work). I could see this potentially being annoying since you could write subclasses that don’t need to be logical. It’s not black and white.

There is actually an example in the JDK (javax.security.auth.Subject$SecureSet). This class subclasses AbstractSet but doesn’t use any hashing to do it’s job of being a Set.


Fiona OShea 2007-04-04

Log a warning in console for unsupported subclasses

Tim Eck 2007-04-20

to the best of my recollection, the warning will be issued for any included class that is a subclass of AbstractSet or AbstactMap *and* is not in the set of classes we know are functional.