New Integer VS Valueof

New Integer vs valueOf

Integer.valueOf implements a cache for the values -128 to +127. See the last paragraph of the Java Language Specification, section 5.1.7, which explains the requirements for boxing (usually implemented in terms of the .valueOf methods).

http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.7

Integer.valueOf() better than new Integer()

No, there is no scenario where new Integer() should be used. If you are distinguishing integers by their wrapper object identity then you are not likely to be doing something reasonable.

Method invokes inefficient new Integer(int) constructor; use Integer.valueOf(int) instead

1.) This link suggest that internally(by compiler) m.put("first" , a); is converting in m.put("first" , Integer.valueOf(a));

(On that example, there is a List-ArrayList and here we have Map-TreeMap...FYI). then why editor gives warning? And what should i do? what is the optimized way?

Yes, the compiler knows that m.put("first", a) only accepts objects and thus applies autoboxing. In terms of performance, using autoboxing or writing Integer.valueOf(a) would not make any difference.

On the other hand, new Integer(a) is not really slower than Integer.valueOf(a). The difference is that for small absolute values (default would be -128 to 127) Integer.valueOf(a) will use a cache, i.e. won't create new objects all the time. For all other values it will invoke new Integer(a) anyways.

Example:

Integer.valueOf(1) == Integer.valueOf(1) will yield true

Integer.valueOf(1000) == Integer.valueOf(1000) will yield false

new Integer(1) == new Integer(1) will yield false, as the cache is not used here

2.) If instead of Map, if there is any data structure like HashTable then ???

Why are you asking that? There is HashTable but since it is synchronized it means more overhead than HashMap, so unless you need synchronization stick to HashMap or TreeMap if you need sorting.

3.) Why editor gives Unnecessary boxing to Integer.

It's probably just because of readability (a is shorter than Integer.valueOf(a)).

4.) Why m.put("first" , a) works? Because i am passing primitive variable and map's put() only accept Object. So is it because of auto boxing?

See 1

Difference between Integer.parseint vs new Integer

They use the same implementation :

public Integer(String s) throws NumberFormatException {
this.value = parseInt(s, 10);
}

public static int parseInt(String s) throws NumberFormatException {
return parseInt(s,10);
}

The main difference is that parseInt returns a primitive (int) while the Integer constructor returns (not surprisingly) an Integer instance.

If you need an int, use parseInt. If you need an Integer instance, either call parseInt and assign it to an Integer variable (which will auto-box it) or call Integer.valueOf(String), which is better than calling the Integer(String) constructor, since the Integer constructor doesn't take advantage of the IntegerCache (since you always get a new instance when you write new Integer(..)).

I don't see a reason to ever use new Integer("5"). Integer.valueOf("5") is better if you need an Integer instance, since it will return a cached instance for small integers.

Memory of Integer

Are these two lines equal?

No.

The first line is the same as

Integer i = Integer.valueOf(5);

The compiler rewrites the code to that, which is known as autoboxing.

Refer to the Javadoc for Integer.valueOf:

If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values. This method will always cache values in the range -128 to 127, inclusive, and may cache other values outside of this range.

So, Integer.valueOf(5) == Integer.valueOf(5) (it's the same instance returned each time) whereas new Integer(5) != new Integer(5) (a new instance is created each time).

But in all cases - as with all objects in Java - the Integer object is on the heap.

What is performance difference between Integer.valueOf() and Autoboxing

This question is strongly related to this question. As already said in the comments and in the answer to the linked question,

autoboxing invokes the static method Integer.valueOf(), and autounboxing invokes intValue() on the given Integer object. There's nothing else, really - it's just syntactic sugar.

Obviously, the performance is the same. However, things are a bit more complicated as this answer says:

there is no guarantee of how autoboxing is internally implemented.

So, in theory, given some exotic java compiler, the implementation might differ and so might the performance. Practically, there's no reason for implementing autoboxing differently. Moreover, if there was a better implementation, it probably could be incorporated into Integer.valueOf(). So even then, the performance would be the same.

---

In Java, there's usually nothing to gain from using an alternate implementation doing the same. For example, there used to be performance differences between Arrays.copyOf and System.arraycopy, but AFAIK they were optimized away in the Oracle / OpenJDK JVM.

Integer.valueOf() vs. Integer.parseInt()

Actually, valueOf uses parseInt internally. The difference is parseInt returns an int primitive while valueOf returns an Integer object. Consider from the Integer.class source:

public static int parseInt(String s) throws NumberFormatException {
    return parseInt(s, 10);
}

public static Integer valueOf(String s, int radix) throws NumberFormatException {
    return Integer.valueOf(parseInt(s, radix));
}

public static Integer valueOf(String s) throws NumberFormatException {
    return Integer.valueOf(parseInt(s, 10));
}

As for parsing with a comma, I'm not familiar with one. I would sanitize them.

int million = Integer.parseInt("1,000,000".replace(",", ""));

Different between parseInt() and valueOf() in java?

Well, the API for Integer.valueOf(String) does indeed say that the String is interpreted exactly as if it were given to Integer.parseInt(String). However, valueOf(String) returns a new Integer() object whereas parseInt(String) returns a primitive int.

If you want to enjoy the potential caching benefits of Integer.valueOf(int), you could also use this eyesore:

Integer k = Integer.valueOf(Integer.parseInt("123"))

Now, if what you want is the object and not the primitive, then using valueOf(String) may be more attractive than making a new object out of parseInt(String) because the former is consistently present across Integer, Long, Double, etc.

What is the difference between (Integer)y and new Integer(y) in java?

If all you want to do is to convert an int primitive to an Integer object,
you have four options

   Integer in = (Integer)y;         // 1 explicit cast
   Integer in = y;                  // 2 implicit cast (autoboxing)
   Integer in = new Integer(y);     // 3 explicit constructor
   Integer in = Integer.valueOf(y); // 4 static factory method

The most preferable way here is 2 (autoboxing). The explicit constructor (3) is the less preferable, as it might have some small performance hit.

Also, they are not strictly equivalent. Consider:

public static void main(String[] args) {
    int x = 25;
    Integer a = new Integer(x);
    Integer b = new Integer(x);
    System.out.println(a == b);     // false
    Integer c = Integer.valueOf(x);
    Integer d = Integer.valueOf(x);
    System.out.println(c == d);     // true
    Integer e = (Integer)x;
    Integer f = (Integer)x;
    System.out.println(e == f);     // true
}

This is because small integers are cached (details here).

---

Related Topics