5 Replies Latest reply: Apr 22, 2008 3:57 PM by JoachimSauer RSS

    Integer.valueOf( int i ) vs. Integer.valueOf( String s )?

    807591
      an inspection of the implementation ( 1.6.0_04 ) indicates that valueOf( int i ) and valueOf( String s ) differ in an interesting way.

      the former attempts to return an Integer from the internal cache, while the latter always constructs a new Integer after parsing. naively, one might expect valueOf( String s ) to parse to a primitive, then invoke valueOf( int i ).

      i'm guessing the original implementation is preserved to avoid breaking code that depends on unique Integer objects being returned by this method, but i'm not certain.

      am i right, or is this an oversight, or am i missing something (again)?
        • 1. Re: Integer.valueOf( int i ) vs. Integer.valueOf( String s )?
          807591
              public static Integer valueOf(int i) {
               final int offset = 128;
               if (i >= -128 && i <= 127) { // must cache 
                   return IntegerCache.cache[i + offset];
               }
                  return new Integer(i);
              }
              public static Integer valueOf(String s) throws NumberFormatException
              {
               return new Integer(parseInt(s, 10));
              }
          What are you asking?
          • 2. Re: Integer.valueOf( int i ) vs. Integer.valueOf( String s )?
            JoachimSauer
            newark wrote:
            What are you asking?
            It looks like he's asking why valueOf(String) is not implemented like this:
                public static Integer valueOf(String s) throws NumberFormatException
                {
                 return valueOf(parseInt(s, 10));
                }
            And I don't have an answer, but I don't particularly care, either.
            • 3. Re: Integer.valueOf( int i ) vs. Integer.valueOf( String s )?
              807591
              It is slightly weird. The API even says that for certain values, valueOf(int) is faster than calling the constructor. Maybe they thought that typically, Strings being passed would not range from -128 to 127.
              • 4. Re: Integer.valueOf( int i ) vs. Integer.valueOf( String s )?
                807591
                sorry if my original question was unclear. but yes, i'm asking why Integer.valueOf(String s) does not use the cache. Integer.valueOf(int i) was added in 1.5 as part of autoboxing support. the api docs:

                [http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Integer.html#valueOf(int)]

                suggest that this method may yield better performance (inspection revealing this is achieved through the cache added in 1.5).

                if that is a good idea for one factory method, why would it not be for the other?

                the earlier post suggests that when invoked with String, the parsed values are not expected to fall as frequently in the cached range - i suppose that is plausible, but... this part of Integer still feels a bit inconsistent/unexplained.


                • 5. Re: Integer.valueOf( int i ) vs. Integer.valueOf( String s )?
                  JoachimSauer
                  One probable cause is that it's for backwards compatibility. While "valueof(String s)" probably never promised (i.e. "was documented to") return a new unique Integer even for calls with the same Strings, it is possible (and due the amount of code out here: probable) that some code relied on that unspecified behaviour.