 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2006Integer.valueOf(String) doesn't use the cache - why not?
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 > 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 [quoted text clipped - 4 lines] > 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 "Oliver Wong" <owong@castortech.com> wrote or quoted in Message-ID: <WeNYg.22959$P7.16332@edtnps89>: > 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. > "Oliver Wong" <owong@castortech.com> wrote or quoted in > Message-ID: <WeNYg.22959$P7.16332@edtnps89>: [quoted text clipped - 16 lines] > 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 > 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 > 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 > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.