To really demonstrate autoboxing you need to allow the compiler to convert from int to Integer:

    Integer x = 1000;
    Integer y = 1000;

However, if you are after interesting counterintuitive corner cases, change the constant to 100:

    Integer x = 100;
    Integer y = 100;

A direct equality comparison will now compare true because, by default, the JVM caches the Integer objects for values from -128 to +127 (the range can be extended as an optimisation).

In other words, your corner case has a corner case. Magic.


On 2011-05-20 20:22, Martin C.Martin wrote:
John Daughtry brings up a much better example: autoboxing in Java. My favourite corner case:

Integer x = new Integer(1000);
Integer y = new Integer(1000);

x < y // Compares the underlying integers: false
x > y // Compares the underlying integers: false
x == y // Compares the two objects: false


-------- Original Message --------
Subject:     Re: "Magic" features of programming languages
Date:     Fri, 20 May 2011 12:31:53 -0400
From:     John Daughtry <>
To:     Martin C.Martin <>

I don't have a reference, but a more general example...

A great well-known example of this problem being introduced to a
language is auto-boxing in Java
... and the problems it creates when combined with the collections
classes. Bloch outlines this in detail in Java Puzzlers. Why doesn't
this work?

   1 myList.add(10);   //we now have {10}
   2  myList.add(1);   //we now have {10,1}
   3 myList.remove(1); //we now have {1} but we expected {10}

Line 1 uses autoboxing to invoke the method add(Object) while line 3
just calls remove(int).

The "magic", once combined with other features, turned into an
unintuitive mess. It gets even crazier


On Fri, May 20, 2011 at 11:46 AM, Martin C.Martin
< <>> wrote:

    Hi all,

    When a construct is ambiguous, sometimes language designers will
    provide a default which (they hope) does the right thing in the
    common case.  An example is XPath.  When = is called on two sets,
    the semantics are that there is at least one pair of elements (one
    from each set) that compare equal, i.e. that their intersection is

    This is arguably counter-intuitive.  For example, if an XML node
    represents an item from a catalog that comes in multiple colors, and
    you ask whether item1.color = item2.color, in some situations you'd
    be surprised that {Red, Green, Blue} was considered the same as
    {Red, Yellow}.  Other times it's natural, e.g. when you want all
    items that come in Red.

    I have a hunch that, when a concept is genuinely ambiguous,
    providing a default leads to "copy-and-paste" programming where
    programmers don't really understand how a feature works, so they
    just use it in a few canonical forms.  Even though there is a simple
    semantics that's easy to describe, they won't find that semantics
    unless they look in the manual, and many people don't.  Instead,
    they just think it's magic and become confused when they try to do
    complicated things with it.

    Have there been any studies that include a look at such "magic"
    features?  Scripting languages typically favor conciseness, and thus
    can have a fair bit of "magic."


    The Open University is incorporated by Royal Charter (RC 000391), an
    exempt charity in England & Wales and a charity registered in
    Scotland (SC 038302).


  Kevlin Henney
  +44 7801 073 508

Reply via email to