This bug appears to have been present as far back as Java 6 when NavigableSet was introduced. I could only check 6u33 but it seems unlikely to have been broken during the course of Java 6 maintenance releases.
As these are views which pass through mutation to the parent object I believe there are fewer compatibility concerns than might be expected. Compatibility concern would mostly involve use of the returned entrySetView for synchronization. Previously synchronization on the returned views would have been partially ineffectual because a new view object was returned every time. Sharing the returned views would have synchronized correctly but any other access to the source object either directly or through other views would have led to problems with concurrent modification of the source treemap. In the repaired implementation where a single view object is returned synchronization on the views would now be more effective and prevent concurrent race errors. It's possible that new deadlock conditions might be introduced but this seems unlikely. Mike On Nov 14 2012, at 21:05 , David Holmes wrote: > Hi Mike, > > On 15/11/2012 3:49 AM, Mike Duigou wrote: >> Hello all; >> >> A small but useful performance fix for sub-maps of TreeMap: >> >> http://cr.openjdk.java.net/~mduigou/7175464/0/webrev/ >> >> The entrySetView was not being cached. > > Seems a bug that entrySetView was never being set, but given that it wasn't > this may now introduce an incompatability may it not? Even if the spec > permits caching for how long have we always returned a new instance? > > David > >> There is no unit test because either implementation is permissible under the >> specification. The fix only has the effect of improving performance and >> reducing duplicate objects. >> >> Mike
