Question

Edit: As always, great answer in under 5 minutes 🙂 Turns out if I make a tiny change – make the F capital in “float”, I’ll get the output I expected.

class NumberMachine{
      public static void main(String [] args) {
        Integer wi1 = new Integer("420");
        int i = 101;
        Integer wi2 = i*420/101;
        if(wi1 == wi2) System.out.print(" =="); 
        if(wi1.equals(wi2)) System.out.print(" equal"); 
         float f = 1.23f; //if this were Float f..., it'd print Float, not double.
         new NumberMachine().printIt(f);
      }

      void printIt(Float f){
         System.out.println(" Float");
      }
      void printIt(double  d){
         System.out.println(" double");
      }
  }

The output is equal double, which makes no sense to me. I expected equal Float. If I comment out the 2nd printIt, then that’s indeed the output. I just don’t know why, when faced with a choice between the two printIt, the compiler ignored the one whose parameter matched perfectly.

Answer 1

You get the result you do because boxing/unboxing was added late in Java’s life and it was required that pre-existing code not be changed by the addition of the feature. So when you pass in a primitive float to printIt, it gets coerced to a primitive double, because the alternative would mean old (pre-JDK1.4) code would act differently, which was an unacceptable possibility for Sun.

Basically, think if this was pre-JDK1.4 code where boxing was not an alternative, no way could the primitive double get coerced to a java.lang.Float. Adding boxing can’t be allowed to break that.

Reading the question it occurs to me from how you word it you may not see the difference between Float and float, because you refer to the change from capital F to lowercase F as a tiny change, when it really isn’t so tiny. The lowercase version refers to a primitive numeric type, the uppercase version refers to an object that wraps the primitive numeric type, in order to allow numeric stuff to be used in general purpose things like collections. Prior to JDK1.4 if you wanted to do something like this you had to manually write a line like

myList.add(new Float(1.0F));

if you wanted to add a float value to a list. The addition of boxing/unboxing in JDK1.4 tried to paper over this and have the compiler do this for us, but unfortunately you still have to understand the difference between the two to make sense of what’s going on.