Migrating methods in Collections

[Doug Lea]

Isolating one small issue for now:

On 12/23/2015 10:52 AM, Brian Goetz wrote:

>> Doing nothing about List.remove(index) seems to be legal option.
>
> Yes, that's a legal option (just as today, you can overload foo(T) and
> foo(String)).  Not sure if it *should* be a legal option (at the very least, the
> compiler should warn you of this, as it should also probably with overloads that
> fail to follow a meet rule.)
>
>> No
>> existing code will encounter an ambiguity that is not already present
>> due to autoboxing (for List<Integer>). New code using or implementing
>> List<int> will need some way to disambiguate. But I think that some
>> syntax will be needed to allow anyway.  It might be nice introduce
>> method removeAt to reduce need to use this syntax, but doesn't seem
>> necessary?
>
> Can you expand on what you might want for disambiguation here?
>

Not sure; possibly nothing considering that users already (since jdk5)
live with this compiling without warning:

import java.util.*;
public class RemoveInteger {
     public static void main(String[] args) {
         List<Integer> c = new ArrayList<Integer>();
         c.add(1);
         c.remove(1);
         System.out.println(c);
     }
}

Running ...

Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
	at java.util.ArrayList.rangeCheck(ArrayList.java:659)
	at java.util.ArrayList.remove(ArrayList.java:495)
	at RemoveInteger.main(RemoveInteger.java:8)