United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4216399 : (coll) TreeMap: please make getCeilEntry and getPreviousEntry >>public<<

Details
Type:
Enhancement
Submit Date:
1999-03-02
Status:
Resolved
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2005-09-04
Component:
core-libs
OS:
generic
Sub-Component:
java.util:collections
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.2.0
Fixed Versions:

Related Reports

Sub Tasks

Description
Name: dbT83986			Date: 03/02/99


I needed a method to find the next or previous in a TreeMap if
the entry isn't in the collection. There already is a private 
method that does exactly that, but I have no clue why it is 
private. Pretty please make this public (not that i will wait 
for it to become public, but it would be good for all Those 
To Come)

ps: good luck with Java
(Review ID: 52814)
======================================================================

                                    

Comments
WORK AROUND

  To get the predecessor of a given key (k) in a SortedMap m:

          Obejct pred = m.headSet(k).lastKey();

  To get the successor:

     a) If you know that the Map *doesn't* contain an entry for k:

          Object succ = m.tailSet(k).firstKey();

     b) If m might contain an entry for k:

          Iterator i = m.tailSet(k);
          Object succ = i.next();
          if (succ.equals(k))
              succ = i.next();

There are many related alternatives.  For example, these idioms can be tweaked to give values in addition to keys.  See the SortedSet section of the collections tutorial ( http://java.sun.com/docs/books/tutorial/collections/interfaces/sorted-set.html ) for related information.

joshua.bloch@Eng 1999-03-08
                                     
1999-03-08
EVALUATION

   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.
 
joshua.bloch@Eng 1999-03-08

As time passes it becomes clearer that we should find some way to provide this functionality.

###@###.### 2004-01-19

A fix for this will be provided as part of JSR166 maintenance.
###@###.### 2005-03-09 03:02:30 GMT
                                     
2004-01-19



Hardware and Software, Engineered to Work Together