Different Between Parseint() and Valueof() in Java

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 int parseInt(String s) and Integer.valueOf(String s)? Also What is radix with a numerical parameter {10 or etc}

The two methods are almost the same in terms of logic.

The difference is that valueOf returns an Integer and parseInt returns an int.

You can see that both call parseInt(s, 10), which means they treat the input String as a number of radix (base) 10 (i.e. a decimal number).

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

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

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(",", ""));

Difference between Integer.parseInt(“10“); and Integer.valueOf(“10“);

valueOf returns Integer object but parseInt returns int primitive data type

Which one is faster? Integer.valueOf(String string) or Integer.parseInt(String string)?

I would not look at performance. The API says that Integer.valueOf(String) is interpreted the same as if it has been passed to Integer.parseInt(String), except it is wrapped into an Integer. I would look at what you need: an Integer or an int.

Integer.valueOf returns an Integer.

Integer.parseInt returns an int.

Why do == comparisons with Integer.valueOf(String) give different results for 127 and 128?

There's a striking difference here.

valueOf is returning an Integer object, which may have its values cached between -128 and 127. This is why the first value returns true - it's cached - and the second value returns false - 128 isn't a cached value, so you're getting two separate Integer instances.

It is important to note that you are comparing references with Integer#valueOf, and if you are comparing a value that is larger than what the cache supports, it will not evaluate to true, even if the parsed values are equivalent (case in point: Integer.valueOf(128) == Integer.valueOf(128)). You must use equals() instead.

parseInt is returning a primitive int. This is why the third value returns true - 128 == 128 is evaluated, and is of course, true.

Now, a fair bit happens to make that third result true:

  • An unboxing conversion occurs with respect to the equivalence operator you're using and the datatypes you have - namely, int and Integer. You're getting an Integer from valueOf on the right hand side, of course.

  • After the conversion, you're comparing two primitive int values. Comparison happens just as you would expect it to with respect to primitives, so you wind up comparing 128 and 128.

Difference between Long.getLong(s), Long.valueOf(s), Long.parseLong(s) where s is a String Type

Long.getLong(s) does not convert the string inside to long ("123" does not become 123). The string inside is a certain name that the native library will return a long value accordingly.

Long.valueOf(s) when s is string is similar to this one: new Long(Long.parseLong(s))

Long.valueOf(l) when l is a long type will convert the primary data type long to Long. Read about Unboxing and Autoboxing in java

Long.parseLong(s) will convert the string inside to long value.

So they are all different except for Long.valueOf(l) and Long.parseLong(s) they are almost the same however the first one returns a Long object and the other one returns a long the primary data type.

Why does parseInt warn of using valueOf

Can someone explain what exactly the comment warns me about (and the context where valueOf shouldn't be used), and what could possibly go wrong.

The Integer class creates and maintains a cache of Integer objects representing small integer values; by default, values in the range -128 to 127 are covered (more discussion here, here, and many other places). Integer.valueOf() will return an object from this cache when its argument represents a number in the range. The comment is warning that parseInt() must not rely on valueOf() because the former may be invoked before that cache is populated.

The misbehavior that could be expected in that case is not specified, and conceivably might vary between Java versions, but plausible possibilities are that null would be returned or an exception (NullPointerException, IndexOutOfBoundsException, ...) would be thrown.

In any case, this is an internal comment in the implementation, not a comment to users of class Integer. By the time any user code runs, the necessary cache initialization is complete, and Integer.valueOf() can be relied upon to behave fully as its API documentation describes.

Java using Integer.parseInt for comparison

I thought parseInt returns a primitive, not an object like valueOf does.

parseInt returns an int but you assign it to an Integer variable, which causes auto-boxing. Since an int whose value is 444 is being auto-boxed two times, each time a new Integer instance is created (since the Integer cache cannot be used for that value), so comparing them with == returns false.

If you'll assign the output of parseInt to an int, the comparisons will return true in both cases:

int x1 = Integer.parseInt("4");
int y1 = Integer.parseInt("4");
int x2 = Integer.parseInt("444");
int y2 = Integer.parseInt("444");

System.out.println(x1==y1); // true
System.out.println(x2==y2); // true


Related Topics



Leave a reply



Submit