Strings are objects in Java, so why don't we use 'new' to create them?

Question

We normally create objects using the new keyword, like:

Object obj = new Object();

Strings are objects, yet we do not use new to create them:

String str = "Hello World";

Why is this? Can I make a String with new?

Beezer

You should also have a look on this question https://mcmap.net/q/36963/-java-wrapper-equality-test – Smoothspoken

Because string literals are already objects. – Rushy

Note that new String(...) has been used to circumvent an implementation detail when substringing large strings. This was fixed in Java 7 and is not necessary any more. – Interviewee

Answer 1

In addition to what was already said, String literals [ie, Strings like "abcd" but not like new String("abcd")] in Java are interned - this means that every time you refer to "abcd", you get a reference to a single String instance, rather than a new one each time. So you will have:

String a = "abcd";
String b = "abcd";

a == b; //True

but if you had

String a = new String("abcd");
String b = new String("abcd");

then it's possible to have

a == b; // False

(and in case anyone needs reminding, always use .equals() to compare Strings; == tests for physical equality).

Interning String literals is good because they are often used more than once. For example, consider the (contrived) code:

for (int i = 0; i < 10; i++) {
  System.out.println("Next iteration");
}

If we didn't have interning of Strings, "Next iteration" would need to be instantiated 10 times, whereas now it will only be instantiated once.

Paluas

By using String a = new String("abcd"), does it means two string with similar content are present in memory. – Smoothspoken

Right - the compiler will not necessarily check to see if such a String has already been interned (though you could certainly write one that did). – Paluas

yes, this optimization is possible because strings are immutable and therefore can be shared without problems. the shared "asdf" handling is an implementation of the 'Flyweight' design pattern. – Witmer

No one said that it isn't possible, only that it isn't guaranteed. Was that your downvote? – Paluas

What do you mean by "== tests for object equality"? This doesn't seem true to me, but perhaps you meant something different from what this seems to mean. – Tarsier

In your example, is a == b; always necessarily true? If a is not used further in the code, there is no guarantee that it hasn't been garbage-collected before String b = "abcd"; is executed. In that case, your compare a==b will be comparing a real String reference (b) to nothing (what used to be a pointer to a). – Admixture

"Physical equality" is often referred to as "equal identity". – Zoe

I thought == only returns true, if the two string objects are in the memory location and containing the same chracters? – Numerate

@MCEmperor It is referred to as 'identity'. – Rushy

@WhyGeeEx: a==b is a use of a, so no garbage collection can have occurred (and it’s guaranteed to be false in the new case because they’re definitely different objects). – Xenos

Answer 2

Strings are "special" objects in Java. The Java designers wisely decided that Strings are used so often that they needed their own syntax as well as a caching strategy. When you declare a string by saying:

String myString = "something";

myString is a reference to String object with a value of "something". If you later declare:

String myOtherString = "something";

Java is smart enough to work out that myString and myOtherString are the same and will store them in a global String table as the same object. It relies on the fact that you can't modify Strings to do this. This lowers the amount of memory required and can make comparisons faster.

If, instead, you write

String myOtherString = new String("something");

Java will create a brand new object for you, distinct from the myString object.

Ingmar

Hey ... it doesn't require "infinite wisdom" to recognize the need for some kind of syntactic support for string literals. Just about every other serious programming language design supports some kind of string literal. – Tack

Hyperbole has been reduced to stun, Captain :) – Ingmar

Answer 3

String a = "abc"; // 1 Object: "abc" added to pool

String b = "abc"; // 0 Object: because it is already in the pool

String c = new String("abc"); // 1 Object

String d = new String("def"); // 1 Object + "def" is added to the Pool

String e = d.intern(); // (e==d) is "false" because e refers to the String in pool

String f = e.intern(); // (f==e) is "true" 

//Total Objects: 4 ("abc", c, d, "def").

Hope this clears a few doubts. :)

Eriha

String d = new String("def"); // 1 Object + "def" is added to the Pool -> here "def" would be added to the pool only if it's not there yet – Farouche

@southerton Meaningless. It already is in the pool. It was placed there by the compiler. – Rushy

@EJP why (e==d) is false here? they are both refering to the same object "def" in the pool right ? – Lovesome

String c = new String("abc"); // 1 Object ... is this statement correct? If "abc" already referenced from the constant pool then what is the use of inter method? – Hildredhildreth

@Lovesome No, d refers to a new String, while e reters to its interned version. – Rushy

@Rushy so what is the value of d and what is the value of d.intern()? What will be the value of e and e.intern()? And lastly, what will be the value of f? – Gnostic

Answer 4

We usually use String literals to avoid creating unnecessary objects. If we use new operator to create String object , then it will create new object everytime .

Example:

String s1=“Hello“;
String s2=“Hello“;
String s3= new String(“Hello“);
String s4= new String(“Hello“);

For the above code in memory :

Goshorn

Answer 5

It's a shortcut. It wasn't originally like that, but Java changed it.

This FAQ talks about it briefly. The Java Specification guide talks about it also. But I can't find it online.

Borodino

Broken link, and I am not aware of any other evidence that it was ever changed. – Rushy

@EJP It's still in the wayback machine if that's useful. – Inquisition

Answer 6

String is subject to a couple of optimisations (for want of a better phrase). Note that String also has operator overloading (for the + operator) - unlike other objects. So it's very much a special case.

Jule

The + is actually an operator which is translated into a StringBuilder.append(..) call. – Loader

Answer 7

In Java, Strings are a special case, with many rules that apply only to Strings. The double quotes causes the compiler to create a String object. Since String objects are immutable, this allows the compiler to intern multiple strings, and build a larger string pool. Two identical String constants will always have the same object reference. If you don't want this to be the case, then you can use new String(""), and that will create a String object at runtime. The intern() method used to be common, to cause dynamically created strings to be checked against the string lookup table. Once a string in interned, the object reference will point to the canonical String instance.

    String a = "foo";
    String b = "foo";
    System.out.println(a == b); // true
    String c = new String(a);
    System.out.println(a == c); // false
    c = c.intern();
    System.out.println(a == c); // true

When the classloader loads a class, all String constants are added to the String pool.

Pentomic

"The double quotes causes the compiler to create a String object." undervalued comment – Meshach

Answer 8

Well the StringPool is implemented using The Hashmap in java. If we are creating always with a new keyword its not searching in String Pool and creating a new memory for it which might be needed later if we have a memory intensive operation running and if we are creating all the strings with new keyword that would affect performance of our application. So its advisable to not to use new keywords for creating string because then only it will go to String pool which in turn is a Hashmap ,(memory saved , imagine if we have lots of strings created with new keyword ) here it will be stored and if the string already exists the reference of it(which would usually reside in Stack memory) would be returned to the newly created string. So its done to improve performance .

Aforementioned

Answer 9

Feel free to create a new String with

String s = new String("I'm a new String");

The usual notation s = "new String"; is more or less a convenient shortcut - which should be used for performance reasons except for those pretty rare cases, where you really need Strings that qualify for the equation

(string1.equals(string2)) && !(string1 == string2)

EDIT

In response to the comment: this was not intended to be an advise but just an only a direct response to the questioners thesis, that we do not use the 'new' keyword for Strings, which simply isn't true. Hope this edit (including the above) clarifies this a bit. BTW - there's a couple of good and much better answers to the above question on SO.

Regularize

-1 - Bad advice. You should NOT "feel free" to use new String(...) UNLESS your application REQUIRES you to create a String with a distinct identity. – Tack

I know that. Edited the post for clarification. – Regularize

Answer 10

Syntactic sugar. The

String s = new String("ABC");

syntax is still available.

Trophoplasm

This is not quite right. s=new String("ABC") will not give you the same results as s="ABC". See danben's comment. – Prompt

Also, somewhat ironically, it will first create a String instance representing "ABC" inline - and then pass that as an argument to the constructor call which will create an return a String of identical value. – Argyll

The valid use case for this constructor is String small = new String(huge.substring(int, int));, which allows you to recycle the big underlying char[] from the original huge String. – Genuflect

@PascalThivent yes but not anymore with Java 8. It does not share arrays anymore (in preparation for other optimizations like automatic string deduplication with G1 or upcoming string compression). – Plunkett

@AndrzejDoyle Not correct. The compiler creates the object for the literal. – Rushy

Answer 11

You can still use new String("string"), but it would be harder to create new strings without string literals ... you would have to use character arrays or bytes :-) String literals have one additional property: all same string literals from any class point to same string instance (they are interned).

Hydrastis

Answer 12

There's almost no need to new a string as the literal (the characters in quotes) is already a String object created when the host class is loaded. It is perfectly legal to invoke methods on a literal and don, the main distinction is the convenience provided by literals. It would be a major pain and waste of tine if we had to create an array of chars and fill it char by char and them doing a new String(char array).

Catheryncatheter

Answer 13

The literal pool contains any Strings that were created without using the keyword new.

There is a difference : String without new reference is stored in String literal pool and String with new says that they are in heap memory.

String with new are elsewhere in memory just like any other object.

Dundalk

Answer 14

Because String is an immutable class in java.

Now why it is immutable? As String is immutable so it can be shared between multiple threads and we dont need to synchronize String operation externally. As String is also used in class loading mechanism. So if String was mutable then java.io.writer could have been changed to abc.xyz.mywriter

Mukluk

Answer 15

TString obj1 = new TString("Jan Peter");                
TString obj2 = new TString("Jan Peter");                    

if (obj1.Name == obj2.Name)                 
    System.out.println("True");
else                
    System.out.println("False");

Output:

True

I created two separate objects, both have a field(ref) 'Name'. So even in this case "Jan Peter" is shared, if I understand the way java deals..

Unleash