Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5048399

(coll) please fix anachronisms in collections internal generification

    Details

      Description

      The collections implementations are a template of our suggested practices
      for people writing generic code or generifying their existing code, so it
      should be as clean as possible both externally and internally.

      ======================================================
      Date: Mon, 17 May 2004 09:38:01 -0700
      From: ###@###.###
      Subject: Re: Double fisted casting?
      To: ###@###.###
      Cc: ###@###.###

      ###@###.### wrote:
      >
      >> My code wouldn't compile without the double cast.
      >>
      >> Note that the code below is YOUR code, that I just found in the
      >> library sources. It wouldn't compile without the double cast either.
      >>
      >>
      > It's Sun's code, but I believe ###@###.### parameterized it. That's why I
      > asked him about the double cast.

      OK, there are two things going on here.

      First, the double cast is necessary because doing it as a single cast would
      provoke a compile-time error. The compile-time error is correct: the compiler
      has detected a cast from one type (EntrySet) to another (Set<Map.Entry<K,V>>)
      that could not ever be correct (because EntrySet extends a different,
      non-parameterized version of Set). The double cast hides from the compiler the
      fact that we are doing a cast that is not merely unsafe, but incorrect.

      So why do we have an incorrect cast in the code? The answer is: it was added to
      work around a compiler bug that has long since been fixed. The following code
      in HashMap.java:

           public Set<Map.Entry<K,V>> entrySet() {
               Set<Map.Entry<K,V>> es = entrySet;
               return (es != null ? es : (entrySet = (Set<Map.Entry<K,V>>) (Set) new
      EntrySet()));
           }

           private class EntrySet extends AbstractSet/*<Map.Entry<K,V>>*/ {
               public Iterator/*<Map.Entry<K,V>>*/ iterator() {
                   return newEntryIterator();
               }
               public boolean contains(Object o) {
                   if (!(o instanceof Map.Entry))
                       return false;
                   Map.Entry<K,V> e = (Map.Entry<K,V>) o;
                   Entry<K,V> candidate = getEntry(e.getKey());
                   return candidate != null && candidate.equals(e);
               }
               public boolean remove(Object o) {
                   return removeMapping(o) != null;
               }
               public int size() {
                   return size;
               }
               public void clear() {
                   HashMap.this.clear();
               }
           }

      should be replaced by its correct version:

           public Set<Map.Entry<K,V>> entrySet() {
               Set<Map.Entry<K,V>> es = entrySet;
               return (es != null ? es : (entrySet = new EntrySet()));
           }

           private class EntrySet extends AbstractSet<Map.Entry<K,V>> {
               public Iterator<Map.Entry<K,V>> iterator() {
                   return newEntryIterator();
               }
               public boolean contains(Object o) {
                   if (!(o instanceof Map.Entry))
                       return false;
                   Map.Entry<K,V> e = (Map.Entry<K,V>) o;
                   Entry<K,V> candidate = getEntry(e.getKey());
                   return candidate != null && candidate.equals(e);
               }
               public boolean remove(Object o) {
                   return removeMapping(o) != null;
               }
               public int size() {
                   return size;
               }
               public void clear() {
                   HashMap.this.clear();
               }
           }

      However, since this is all private code, and we are past Tiger beta2 freeze,
      there is not sufficient urgency to do it now. You'll find a number of
      anachronisms hiding inside the implementation of collections due to recent
      language changes, and I hope we have the time to address them soon after Tiger.

      ###@###.###

        Attachments

          Activity

            People

            • Assignee:
              martin Martin Buchholz
              Reporter:
              gafter Neal Gafter
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: