Integer.valueOf(String) doesn't use the cache - why not?

[Oliver Wong]

As we all know, it's preferable to use Integer.valueOf(42) over new
Integer(42), as the former uses a cache to avoid unnescessary object
creation. So it seems strange to me that the Integer.valueOf("42") will
create a new object every time (I'm looking at version 1.92, 04/07/06 of the
class file).

Is there a legitimate reason for this, or might this be something to
submit as a Request For Enhancement to Sun?

- Oliver

 

[Thomas Hawtin]

As we all know, it's preferable to use Integer.valueOf(42) over new
Integer(42), as the former uses a cache to avoid unnescessary object
creation. So it seems strange to me that the Integer.valueOf("42") will
create a new object every time (I'm looking at version 1.92, 04/07/06 of the
class file).

Is there a legitimate reason for this, or might this be something to
submit as a Request For Enhancement to Sun?

The are reasons for using new Integer over Integer.valueOf(int). If it
has to create a new Integer, Integer.valueOf will tend to be slower. So
if you are usually creating non-cached values, valueOf will be slightly
better from a performance perspective.

Which camp Integer.valueOf(String) falls into is debatable. Most of the
Java library still uses the constructor, because that was available when
the code was written and there isn't an overwhelming need to change it.

Tom Hawtin

 

[Red Orchid]

As we all know, it's preferable to use Integer.valueOf(42) over new
Integer(42), as the former uses a cache to avoid unnescessary object
creation. So it seems strange to me that the Integer.valueOf("42") will
create a new object every time (I'm looking at version 1.92, 04/07/06 of the
class file).

I think that no cache of 'valueOf(String s)' is good policy.
Because ..

1) Cache of [-128, 127] requires 255 objects (128 + 127)
even though a related method is called only one time.
2) [-128, 127] is very narrow than [0x80000000, 0x7fffffff].
Namely, [-128, 127] is very special case.

Therefore ..
If 'valueOf(String s)' uses a cache, commonly it is a wasteful
use of memory and cpu.


'valueOf(String s)' do not use cache, but nevertheless
'valueOf(int i)' use cache. It will lead programmers
to confusion.

I think that the cache of 'valueOf(int i)' should be removed
and it is better to add a new method to 'Integer' for cache.

 

[Patricia Shanahan]

As we all know, it's preferable to use Integer.valueOf(42) over new
Integer(42), as the former uses a cache to avoid unnescessary object
creation. So it seems strange to me that the Integer.valueOf("42") will
create a new object every time (I'm looking at version 1.92, 04/07/06 of the
class file).

I think that no cache of 'valueOf(String s)' is good policy.
Because ..

1) Cache of [-128, 127] requires 255 objects (128 + 127)
even though a related method is called only one time.
2) [-128, 127] is very narrow than [0x80000000, 0x7fffffff].
Namely, [-128, 127] is very special case.

Therefore ..
If 'valueOf(String s)' uses a cache, commonly it is a wasteful
use of memory and cpu.

There is nothing preventing the use of the cache only for a selected
range. Note that Oliver's example falls within the range that would be
cached for valueOf(int i).

The simplest way of applying caching to valueOf(String s) would be to
replace its constructor call with a valueOf(int) call.

Patricia

 

[Chris Uppal]

As we all know, it's preferable to use Integer.valueOf(42) over new
Integer(42), as the former uses a cache to avoid unnescessary object
creation. So it seems strange to me that the Integer.valueOf("42") will
create a new object every time (I'm looking at version 1.92, 04/07/06 of
the class file).

I assume the behaviour of Integer.valueOf(String) is determined by backward
compatibility with previous versions. The cache wasn't introduced until 1.5 (at
the same time as valueOf.(int)), but Integer.valueOf(String) has been around
for a long time. It's not a good idea to play games with object identity, so I
presume Sun were reluctant to change the semantics of the existing method.

Of course, the same reluctance to play games with identity should have
suggested that the cache used by valueOf(int) is a bad idea. But presumably
they thought that mitigating (some of) the negative effects of autoboxing was
more important than semantic purity.

-- chris

 

[Thomas Hawtin]

I assume the behaviour of Integer.valueOf(String) is determined by backward
compatibility with previous versions. The cache wasn't introduced until 1.5 (at
the same time as valueOf.(int)), but Integer.valueOf(String) has been around
for a long time. It's not a good idea to play games with object identity, so I
presume Sun were reluctant to change the semantics of the existing method.

I think if you dig up old enough API docs, you'll see that a number of
old methods were specified to return new objects. Those requirements
have been quietly dropped.

http://java.sun.com/j2se/1.3/docs/api/java/lang/Integer.html#valueOf(java.lang.String)
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Integer.html#valueOf(java.lang.String)

If you are going to make such assumptions about how the Java library is
implemented, I think your code deserves not to work. Changing a method
to return different objects instead of the same object is likely to be
more dangerous.

Tom Hawtin

 

[Chris Uppal]

I think if you dig up old enough API docs, you'll see that a number of
old methods were specified to return new objects. Those requirements
have been quietly dropped. [...]
If you are going to make such assumptions about how the Java library is
implemented, I think your code deserves not to work.

You are suggesting that people who program to Sun's documented API deserve what
they get ? Seems a bit extreme...

-- chris