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
andInteger
. You're getting anInteger
fromvalueOf
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 comparing128
and128
.
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
Java Embedded Databases Comparison
How to Use Classes from .Jar Files
Get Domain Name from Given Url
How to Randomize Two Arraylists in the Same Fashion
How to Run Certain Task Every Day at a Particular Time Using Scheduledexecutorservice
Mod in Java Produces Negative Numbers
Lambdas: Local Variables Need Final, Instance Variables Don'T
Java: (String[])List.Toarray() Gives Classcastexception
Why Java Inner Classes Require "Final" Outer Instance Variables
How to Activate Jmx on My Jvm for Access with Jconsole
How to Decompile a Whole Jar File
Tracing Xml Request/Responses with Jax-Ws
Createprocess Error=206, the Filename or Extension Is Too Long When Running Main() Method
Java 1.6 - Determine Symbolic Links
How to Add Image in a Textview Text