title: Javac and Primitives: Boxed vs. Unboxed
body: <p>My question is: why do primitive types have to be wrapped in an object, when it is also a possibility to have the compiler set things right for you?</p>
  
  <ol>
  <li>calls to a primitive value x's methods can be translated from x.call() to X.call(x) - this is what I try to illustrate below.</li>
  <li>generics aren't kept around at runtime (right?), so it isn't the case that you need to access class information at runtime - you could simply replace every instance of Integer by int and rewrite method calls as above, and end up with executable code.</li>
  </ol>
  
  <p>So basically, what I'm asking is: what am I missing here?</p>
  
  <hr>
  
  <p>I've been wondering about this for some time: Why can't the Java compiler translate...</p>
  
  <pre><code>int a = 482;
  int b = 12;
  System.out.println((a + b).toHexString());
  </code></pre>
  
  <p>...to the following code...</p>
  
  <pre><code>int a = 482;
  int b = 12;
  System.out.prinln(Ints.toHexString(a + b));
  </code></pre>
  
  <p>...and thus remove the entire need for boxing and unboxing?</p>
  
  <p>(Thus, compile method calls to (static) function calls, and keep a single instance of Int.class around in case it's needed - e.g. after a call of Ints.getClass(_)?)</p>
  
  <hr>
  
  <p>Comment added for clarity:</p>
  
  <blockquote>
    <p>@Adam: No, I do not think it causes
    boxing/unboxing. The example attempts
    to illustrate how primitives could be
    treated as objects in the language,
    but as primitives by the compiler.
    This would remove the (slight)
    overhead in runtime, and a confusing
    thing in the language. Therefore the
    intended question was exactly: why
    didn't the extremely talented compiler
    developers pick this solution? Because if they didn't, there
    must be a clear impossibility that I'm
    not seeing. And I'd like to know what
    it is. – Pepijn</p>
  </blockquote>