This is a known deficiency in TreeMap (the SortedMap interface actually), but there are satisfactory workarounds (described in the workaround field of this bug report). We thought hard about this when we designed the interface and made a conscious decision not to export these methods in the interface. The main reasons for the decision (to the best of my recollection) are:
1) The methods would be, in effect, an alternative form of iteration.
Currently, *ALL* iteration over Maps is done via "Set-views". We
were loath to give up the consistency.
2) There are *three* iterable Set views: keys, values and entries. Thus,
adopting the suggestion would have added six rather than two calls
to the Map API (or left obvious holes in it). Consistency would have
forced us to add six analogous methods to TreeSet. Twelve new calls
in the core collection interfaces seemed excessive.
3) It would have raised the issue of what to do when there is no next
(or previous) entry. Because null is a legitimate key/entry value, we
would have pretty much been forced to throw a NoSuchElement exception.
We were afraid that people would have used the new methods to iterate over
Sorted Sets/Maps, terminating the iteration by catching the exception.
This would be unacceptable from a performance and style point of view:
throwing exceptions is very expensive, and using (unchecked!) exceptions
for normal control flow is very much frowned upon.
As time passes it becomes clearer that we should find some way to provide this functionality.
A fix for this will be provided as part of JSR166 maintenance.
###@###.### 2005-03-09 03:02:30 GMT