p.lord@cs.man.ac.uk wrote in comp.lang.java.programmer:

    Correct. But then, there is no requirement for a programming
    language to be type safe either.

    And I was not challenging type safety or whether autoboxing
    should be type safe. Only pointing out that in the example
    code of the original article there were no facts involved,
    only assumptions.

Lee Fesperman wrote [quoted in full for reasons that will become evident]:

I can't be bothered with this.

   -- chris

Lee Fesperman <firstsql@ix.netcom.com> wrote or quoted:

Since such languages include Python, C#, Ruby, Scheme, Dylan, ML,
and Smalltalk I'd say yes.

I don't want to sound hostile, but this is completely wrong.

Take a look at a typical Smalltalk implementation.  (BTW, this post isn't
intended as a plug for Smalltalk -- though readers are welcome to take it that
way if they wish -- but as an experience report from someone who has used a
language with the features under discussion.)

The typical /implementation/ strategy is the old "unboxed representation" trick
(encoding smallish int values in what otherwise would be a pointer to an
object's physical representation -- /NOT/, please note, auto-boxing, which
would indeed be a performance problem).  This does cause a small slowdown
relative to the use of "raw" primitive types, which -- in the case of
Smalltalk -- is exacerbated by the dynamic nature of its type system making it
harder (but not impossible) for the JIT to optimise arithmetic operations, but
the slowdown is fairly small (I don't have figures for modern implementations,
but I'd guess 10-20% for raw arithmetic) and would easily be accommodated for
/most/ purposes.

For integer values that need more than about 30 bits the system must switch to
a boxed representation.  That indeed causes a noticeable slowdown (mainly
because of all the object allocations), but on the other hand there is no
problem with integer overflow (I still can't understand why Java -- supposedly
so safe -- allows /silent/ integer wraparound by default).

That's the implementation side.  Now for the semantics.  To be honest I don't
really understand what you think the problem would be.  In Smalltalk integers
are objects, and that causes no problems that I can see.  It's not obvious to
me what value "value semantics" would be supposed to add.  Integers are either
BigIntegers (boxed) or SmallIntegers (unboxed), both are subclasses of Integer.
Integer and Float are subclasses of Number.  Normal class-based polymorphism is
used extensively and in complete accordance with how all the other objects
work.  No need for "widening conversions", overloaded arithmetic operators (0.1
+ 22) and all the other junk that Java has to add to its semantics in order to
hack around the problems caused by primitive types.  It all works very well.

BTW, I'm not saying that it would be appropriate for a language like Java not
to have primitive types at all.  The nature of the language (specifically its
type system) means that they could be included as an expert-friendly feature
available for use by people who knew what they were doing when (say) adding two
integers together, or comparing two floats.  But what I /do/ think is that
machine primitives should never have been the /default/ representation of
numbers.

   -- chris

Bent C Dalager <bcd@pvv.ntnu.no> wrote or quoted:

Java 5 caches integers smaller than 128 and bigger than -129.

Earlier versons do not - leading to non-backwards-compatible behaviour:

``Immutable Objects
 
 Consider the following code fragment:
 
    Integer i1 = 100;
    Integer i2 = 100;
    Integer i3 = 1000;
    Integer i4 = 1000;
    System.out.println(i1==i2);
    System.out.println(i3==i4);
 
 Can you guess what will be printed on the screen? If your
 answer is false--well, you're wrong.
 
 In this case, J2SE 5.0 works differently. Certain ranges of
 values are stored as immutable objects by the Java Virtual
 Machine. So, in this case, the output is:
 
 true
 false
 
 Normally, when the primitive types are boxed into the
 wrapper types, the JVM allocates memory and creates a new
 object. But for some special cases, the JVM reuses the same
 object.
 
 The following is the list of primitives stored as immutable
 objects:
 
     * boolean values true and false
     * All byte values
     * short values between -128 and 127
     * int values between -128 and 127
     * char in the range \u0000 to \u007F''

- http://today.java.net/pub/a/today/2005/03/24/autoboxing.html

 Chris> There's nothing wrong (for most purposes) with stuffing a few
 Chris> int-s into a Collection using auto-boxing.  The problem is
 Chris> that that doesn't scale, but it /looks/ as if it is harmless.

 Chris> (For a recent example on this ng: the gent who was keeping
 Chris> around 10 million 32-bit int-s in ArrayLists -- and couldn't
 Chris> understand why he was running out of memory.

Of course, this is true. Although this does turn in to a having cake
and eating it argument.

The whole point of autoboxing is that it is automatic, and doesn't
require programmer annotation.

There are a lot of things like this in Java. The automation of GC for
example, can lead you to leave large numbers of objects dangling on a
static variable (been there, done that...)

Cheers

Phil