Compiler not inferring legal methods correctly?

Question

The following sample code:public class Tester {
  public static <E extends Integer> void doit ( final E[] a ) {
    System.out.println ( a[0] / 4 ) ;
  public static void main ( final String[] args ) {
    Tester.doit ( new Integer[] { 2 , 3 , 4 } ) ;           
}results in the error message:
Tester.java:3: cannot find symbol
symbol : method intValue()
location: bound of type variable E
System.out.println ( a[0] / 4 ) ;
^
Fatal Error: Unable to find method intValue
I think the compiler is wrong here but then I may be wrong :-) The type parameter E has least upper bound Integer and so the compiler knows that a[0] is required to have an intValue method (from Number). The issue is nothing to do with the method being static as you get the same error message with a non-static method.
I suspect that the compiler is treating E as having least upper bound of Object since it can find the toString method -- you can show this by removing the "/ 4" from the code.

Answer 1

Note that this is an autoboxing bug. It's only tangentially related to generic syntax.It is an autoboxing issue but it is also a type lookup issue in the compiler relating to bounds on a type parameter. I am not sure you would get the problem except with generic methods but I haven't tried so I may be talking b$$$$$$$.
Are you saying you want to extend Integer to create classes that are doing other things than just being integers?Actually I would like to be able to extend Integer (and Long) to create subrange types that are primitive integer values boxed with fixed range. This is trivial in C++ (see http://www.russel.org.uk/subrange.html) and I was investigating doing the same thing in Java.
Wouldn't it be better to create an interface like RadixSortable which would supply an int representation of the Object?Unfortuately it is Integers that need to be sorted and they could not be made RadixSortable :-(
I have a class RadixSort with a method sort. I am fiddling with various implementations to show design decisions so there isn't just one solution that I am interested in -- the library is for teaching and so having examples of different design issues is important unlike Collections and JGL where you just need the right functionality with the fastest possible implementation.
The reason they are final is that they are the primitve wrapper classes. To behave like primitives, they must be immutable. If they were extensible, mutable Integer types could be created.Is this certain? If the state is private the subclasses could not change the value and immutability is retained. What I wanted was the ability to create subrange integral types which could use expression syntax.
(Given the way Java is organized real subrange types are seemingly impossible but . . . )
I'm not sure how improving Number (I agree it could be improved upon) would solve your issues. I am not sure there is a problem with Number per se since the methods that are common to Short, Integer, Long, Float and Double are few and far between. What I think is missing is the notions of integral (Short, Integer, Long) to allow algorithms that do not actually depend on the bounds of values representable.
However this is all diverging far from the "generics" issues that this forum is about :-)