Date: Tue, 6 May 2003 14:21:33 -0400 (EDT)
From: C. Scott Ananian
To: jsr14-prototype-comments@sun.com
Subject: 'checkcast' in bridge methods?

It seems that the 1.0-1.3 prototype compilers are adding 'checkcast'
instructions on the parameters to bridge methods, presumably to try to
thrown exceptions earlier, rather than later.  Unfortunately, this
added check may adversely affect backwards-compatibility.  A quick
example:

  import java.util.*;
  class Foo extends AbstractSet<Integer> {
    public int size() { return 0; }
    public Iterator<Integer> iterator() { return null; }
 
    public static void main(String[] args) {
       ((Set)new Foo()).add("a string");
    }
  }

I believe that the correct behavior here is to throw an
UnsupportedOperationException (which is what the program does if you
remove the parameterization) rather than a ClassCastException.

This issue came up in a test suite for collections implementations
(in this case, a test case for Map.entrySet().add(), which should
always throw UnsupportedOperationException), because some JSR-14-ized Map
implementations actually return a Set<Map.Entry<K,V>> for entrySet()
(as opposed to simply *declaring* that they do, as HashMap does).
If HashMap were ever truely genericized, the behavior of
HashMap.entrySet().add() would change for legacy code, as the parameter
would be unavoidably cast to Map.Entry.  This is probably unintended.
 --scott

Washington Clinton Sabana Seca SSBN 731 security Justice Japan anthrax 
ammunition Treasury biowarfare ASW assassination Albanian cracking 
                         ( http://cscott.net/ )