30

I'm consolidating code written by two different people and notice that casting a String value into a Long has been done in two different ways.

Coder #1 has done this:

String strId = "12345678";
...
Long lId = new Long(strId);

While coder #2 has done this:

String strId = "12345678";
...
Long lId = Long.valueOf(strId);

Functionally, the code operates exactly the same. There's a try/catch block around each bit to handle any NumberFormatException that is thrown. The incoming string value is an 8 digit string that represents a decimal: "12345678" and in both cases it is correctly converted into Long.

Is there any functional difference between passing the string in the constructor and using Long.valueOf()? I've checked the constructor doc here:

Long(java.lang.String)

and the docs for valueOf() here:

Long.valueOf(java.lang.String)

As far as I can tell, they both call parseLong() so it doesn't matter which is used. I just want to make sure I'm not setting myself up for some strange behavior further down the road. Also, is either style more "correct" (haha) than the other?

MartyIX
  • 27,828
  • 29
  • 136
  • 207
AWT
  • 3,657
  • 5
  • 32
  • 60

6 Answers6

30

The difference is that using new Long() you will always create a new object, while using Long.valueOf(), may return you the cached value of long if the value is between [-128 to 127].

So, you should prefer Long.valueOf method, because it may save you some memory.

If you see the source code for Long.valueOf(String), it internally invokes Long.valueOf(long), whose source code I have posted below: -

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

public static Long valueOf(long l) {
    final int offset = 128;
    if (l >= -128 && l <= 127) { // will cache 
        return LongCache.cache[(int)l + offset];
    }
    return new Long(l);
}
Rohit Jain
  • 209,639
  • 45
  • 409
  • 525
  • This is exactly what I understood before looking up this http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/lang/Long.java Could you please share the source link. – Arun Manivannan Oct 30 '12 at 18:32
  • 2
    @ArunManivannan.. You can find the source code in the jdk installation directory. Go to `C:\Program Files\Java\jdk` there will be an `src` folder. Might be in zipped format. Unzip it. Go to `java -> lang -> Long.class` to see the source code. – Rohit Jain Oct 30 '12 at 18:33
  • This is very helpful, thanks for the code snippet and the explanation. – AWT Oct 30 '12 at 18:55
  • @torgis. You're welcome :). Whenever you have doubt on some method. Remember, you always have the source code to check. In your `JDK` Installation directory. You just need to know the appropriate package name to search in. – Rohit Jain Oct 30 '12 at 19:01
  • It may save memory but usually it will waste processor time – kukis Apr 23 '15 at 11:44
8

Long.valueOf() should be preferred: it returns cached values of Long for some often-used values instead of constructing a new instance as the constructor does.

Even if some Java versions don't use a cache, using valueOf() makes it possible in future versions, whereas the constructor will always create a new instance.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • That value range is `[-128 to 127]` to be specific. But, I think that can be changed. Don't know how exactly. – Rohit Jain Oct 30 '12 at 18:37
3

They mean the same 

public static Long valueOf(String s) throws NumberFormatException{
        return new Long(parseLong(s, 10));
}

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

Source JDK 6.0

Arun Manivannan
  • 4,213
  • 3
  • 29
  • 38
  • Arun, they are same if the s is out of some range(-128 t0 127), if s in with-in range, they are not same. – kosa Oct 30 '12 at 18:24
  • Which version of Java are you using? In my Java 6 and 7 versions, a cache is used. – JB Nizet Oct 30 '12 at 18:24
  • @Nambari I thought so too. However, the implementation is surprising. – Arun Manivannan Oct 30 '12 at 18:26
  • @JBNizet Thanks for the note. 6.0. Edited the post accordingly. – Arun Manivannan Oct 30 '12 at 18:26
  • You first method does not return `new Long(parseLong(s, 10));` rather `Long.valueOf(parseLong(s, 10));`. See my post. – Rohit Jain Oct 30 '12 at 18:26
  • 2
    Even in JDK 6 they don't **literally** mean the same; they just happen to have the same behavior. Their **meaning** is defined by the Javadoc. – Marko Topolnik Oct 30 '12 at 18:26
  • @MarkoTopolnik Ouch. That was painful. Cutting off **literally** from the answer – Arun Manivannan Oct 30 '12 at 18:29
  • The point is not in the "literally", but in the fact that, at least in Java, implementation code is not the specification, so you cannot make arguments about the meaning of methods by demonstrating their implementation. If this were Ruby, on the other hand, you'd be much more entitled to it. – Marko Topolnik Oct 30 '12 at 18:35
3

Both do parseLong(String, int) internally (int being radix with value as 10), but valueOf has advantage as documented below:

If a new Long instance is not required, this method should generally be used in preference to the constructor Long(long), as this method is likely to yield significantly better space and time performance by caching frequently requested values.

Yogendra Singh
  • 33,927
  • 6
  • 63
  • 73
0

This is the PMD plugin out put which is run on eclipse

Code I checked is 

Long l = new Long("123456");

In JDK 1.5, calling new Long() causes memory allocation. Long.valueOf() is more memory friendly.

someone
  • 6,577
  • 7
  • 37
  • 60
0

i am thinking how to change range and size of the cache for our application, overloaded with Longs;

such change is not supported by j2se api One way is to change loaded java byte code with ClassLoader or even with JVMTI (it allows to keep such trick out of the project, like external tuning)

or, may be, to create external cache and own static cachedValueOf() which is straight forward, but the code depending on some not applicational needs is not nice

Yegor Parusymov
  • 1
  • 1