It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I was looking into the String API and suddenly I came across one String empty Constructor i.e. we can construct an empty String object using String s = new String()
I wonder is there any use of it?
Ofcourse.....
String s = new String();
will create a Non-literal String object on the heap, which will be garbage collected.
where as
String s = "" ;
will create a String Literal. This will not be garbage collected ever, if it is reachable through the default loader.
See this link below to a question which I asked. This may not be directly related to your question, but it will certainly help you grasp the concept firmly.
Is String Literal Pool a collection of references to the String Object, Or a collection of Objects
It creates the empty string, which appears to have some limited use.
If you'll be building up a String by concatenating, and aren't using e.g. StringBuiler, your code can begin as one of the following.
String result = new String();
String result = "";
String result = "first part of string";
// ...
result += "append to the result";
The first two aren't equivalent, and you should prefer to initialize with "" since this can take advantage of string interning.
Small example... String can be garbage collected
System.out.println(1 + new String() + 2);
instead of
System.out.println(1 + "" + 2);
According to the documentation, this constructor creates an empty sequence.
public String()
Initializes a newly created String object so that it represents an empty character sequence. Note that use of this constructor is unnecessary since Strings are immutable.
If you want an empty sequence, it makes sense.
But normally, it wouldn't be necessary to use the empty constructor before you make changes to it, since you are not changing the String. In fact, when you change using the operator += for example, you are creating another immutable String, and not changing one.
Check this question about this subject: How do String objects work (like immutable objects)?
Some background first
Because Strings in Java are immutable, they are also "interned" - that means that all the string literals in the loaded classes are kept in a pool, so there is usually only one instance of each unique string literal in memory at one time. It is an application of the flyweight pattern, similar pools are also kept for Integer and other primitive wrapper objects (but only for a limited number of small values).
Because of this mechanism, identity comparison of string literals (even from different classes) is usually possible (although you should always use equals method when comparing strings for safety and consistency):
System.out.println("hello" == "hello"); // true
Now, if you use the default string constructor, you get an instance of an empty string, but it is a new instance, as stated in JavaDoc:
Initializes a newly created String object so that it represents an empty character sequence. Note that use of this constructor is unnecessary since Strings are immutable.
Such new instance is different from the interned empty string, resulting in:
System.out.println(new String() == ""); // false
But as I said, only string literals are automatically interned - that means strings created manually by StringBuilders, from char arrays etc. are not interned. You can use the String.intern() method to put such a string into the pool manually.
Now for some real scenario
Well all this is nice indeed, but I still haven't answered why this constructor exists. Well, Java strings are just smart wrappers over char arrays and some distinct string objects can share their internal arrays.
If I create a very long string (by reading from a stream for example), then this instance isn't interned (as said above), so it will be garbage collected after the variable that referenced it gets out of scope. But if do this:
String longString = readVeryLongString();
String shortString = longString.subString(0, 10);
... then the new shortString will not copy first 10 characters from the longString and put them into its own new char array. No, it will reference the original array, using only first 10 chars from it.
Now, if the shortString variable has longer life (for example is put into some static context), then the underlying char array will not be garbage collected (even if the original longString variable already got out of scope). This is one of the ways how to create a memory leak in Java.
Now, the default string constructor comes to the rescue! If I change the code above to this:
String longString = readVeryLongString();
String shortString = new String(longString.subString(0, 10));
... then the shortString will be a new string instance that made a new internal char array by copying only the 10 required chars from the original string returned by the subString method.
A nice article illustrating this subject:
http://illya-keeplearning.blogspot.cz/2009/03/java-string-internals.html
to create an empty string,call default constructor as
String s new String();
will create an instance of String with no characters in it.
Related
I am aware that when we initialize a string literal to a variable this literal will be stored in the string pool by the JVM. Consider the piece of code below.
System.out.println("This is a string literal");
Does the string literal within the quotes also be stored in the string pool even if I don't initialize it to a variable?
I will preface this answer by saying that there is little practical use in gaining a deep understanding of the Java string pool. From a practical perspective, you just need to remember two things:
Don't use == to compare strings. Use equals, compareTo, or equivalent methods.
Don't use explicit String.intern calls in your code. If you want to avoid potential problems with duplicate strings, enable the string de-duplication feature that is available in modern Java GCs.
I am aware that when we initialize a string literal either using the 'new' keyword or not, this literal will be stored in the string pool by the JVM.
This is garbled.
Firstly, you don't "initialize" a string literal. You initialize a variable.
String hi = "hello"; // This initializes the variable `hi`.
Secondly you typically don't / shouldn't use a string literal with new.
String hi = new String("hello"); // This is bad. You should write this as above.
The normal use-case for creating a string using new is something like this:
String hi = new String(arrayOfCharacters, offset, count);
In fact, creation and interning of the String object that corresponds to a string literal, happens either at the first time that the literal is used in an expression or at an earlier time. The precise details (i.e. when it happens) are unspecified and (I understand) version dependent.
The first usage might be in a variable initialization, or it might be in something else; e.g. a method call.
So to your question:
Consider the piece of code below:
System.out.println("This is a string literal");
Does the string literal within the quotes also be stored in the string pool even if I do not initialize it?
Yes, it does. If that was the first time the literal was used, the code above may be the trigger for this to happen. But it could have happened previously; e.g. if the above code was run earlier.
As a followup, you asked:
Why does the String Pool collect string literals which are not stored in a variable and just displayed in the console?
Because the JLS 3.10.5 requires that the String objects which correspond to string literals are interned:
"Moreover, a string literal always refers to the same instance of class String. This is because string literals - or, more generally, strings that are the values of constant expressions (§15.28) - are "interned" so as to share unique instances, using the method String.intern (§12.5)."
And you asked:
The Presence of the String Pool help optimize the program. By storing literals as such (which is actually not required because it is just to be displayed in the console), isn't it the case that it goes against its whole purpose (which is optimization)?
The original idea for interning and the string pool was to save memory. That made sense 25 years ago when the Java language was designed and originally specified. These days even a low-end Android phone has 1GB of RAM, and interning of string literals to save a few thousand bytes is kind of pointless. Except that the JLS says that this must happen.
But the answer is No, it doesn't go against the (original) purpose. This statement:
System.out.println("This is a string literal");
could be executed many times. You don't want / need to create a new String object for the literal each time that you execute it. The thing is that the JVM doesn't know what is going to happen.
Anyway, the interning must happen because that is what the spec says.
This question already has answers here:
Java String Immutability and Using same string value to create a new string
(4 answers)
Closed 7 years ago.
i know Strings are immutable in java and i just read some theory about it
Once a String is declared it cannot be changed . i declared a String and changed it's value just by appending some value to it . it should not have happened
String s = "amol";
s = s + "abc";
System.out.println(s); //output is amolabc
The String s didn't get changed. When you did s + "abc", it created a new String object with the result of the operation.
You need to understand the concept of String Pool in Java. Please go through the link
http://www.javaranch.com/journal/200409/ScjpTipLine-StringsLiterally.html
You are right that Strings are immutable. Here, You didn't change the String s. All distinct Strings are stored in the Heap Memory. So, all the variables (say 10 variables ) containing the same String (say "Hello" ) will occupy only 5 bytes of memory. They all will point to the same location. Separate instances will not be stored for each of those variables.
Here, when you write s = s + "abc", a new string "amolabc" is created in the heap,and now the variable s just points to the new string in the heap. You didn't modify the value of "amol". You just made a new String.
The meaning of immutable is not like you thought to be.Being immutable guarantees that hashcode will always the same, so that it can be cashed without worrying the changes.That means, there is no need to calculate hashcode every time it is used.
here you are appending another string value to it,which can be done.But you cannot concatenate with another string.
By appending it is creating another string.
Refer here
This question already has answers here:
How many objects are being created? [duplicate]
(2 answers)
Closed 9 years ago.
How many string objects will be created by the following code?
String s="";
s+=new String("a");
s+="b";
I had this question at exam. I want to know the right answer . I said 2 objects.
The object from pool that contains "" , "b" and the object created by new String("a");
I'll anwser to another, clearer question: how many String instances are involved in the following code snippet:
String s="";
s+=new String("a");
s+="b";
And the answer is 6:
the empty String literal: "";
the String literal "a";
the copy of the String literal "a": new String("a");
the String created by concatenating s and the copy of "a";
the String literal "b"
the String created by concatenating s and "b".
If you assume that the three String literals have already been created by previously-loaded code, the code snippet thus creates 3 new String instances.
String s="";
creates no objects.
s+=new String("a");
creates five objects. the new String, the StringBuilder and its char[] and the String resulting and its char[]
s+="b";
creates four objects, the StringBuilder and its char[] and the String resulting and its char[]
So I get a total of nine objects of which are three String objects
Note: You can be sure that "" has already been loaded as it appear in many system classes including ClassLoader and Class.
The Strings "a" and "b" may or may not be considered as new Strings for the purpose of this question. IMHO I wouldn't count them as they will only be created at most once and if this code is only run once, it hardly matters how many strings are created. What is more likely to be useful is to know how many objects are created each time the code is run.
The number of objects actually created in a JITC situation is indeterminate. The JITC may well recognize that new String("a") is an identity, and that no intermediate values of s are referenced, so that only the StringBuilder is created. There are several potential side-effects that must be mimicked in the general case (eg, where the argument to new String() may be invalid), but with literals they can't occur.
In fact, javac could very well recognize that the result is "ab", with no potential side-effects, and just produce a String literal of that value. (It does string combining in slightly less complicated cases.)
Creating New Strings
Earlier we promised to talk more about the subtle differences between the various methods of creating a String. Let's look at a couple of examples of how a String might be created, and let's further assume that no other String objects exist in the pool:
String s = "abc"; // creates one String object and one reference variable
In this simple case, "abc" will go in the pool and s will refer to it.
String s = new String("abc"); // creates two objects, and one reference variable
In this case, because we used the new keyword, Java will create a new String object in normal (nonpool) memory, and s will refer to it. In addition, the literal "abc" will be placed in the pool.
From SCJP Sun Certified Programmer for Java 6 Study Guide (Exam 310-065).pdf
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What's the advantage of a String be Immutable?
Strings are Immutable?
String s = "PROJECT";
Here s cannot be modified. But String s2=s.toLowerCase() will return me a new string. Here still I can get a new copy of the original string! But if Java still wants immutability, then why not restrict the user while modifying the string (throw an exception or something). Then why immutability? Can any one explain why?
There's a little misconception:
s isn't immutable. s can easily be assigned a new value (i.e. another refence to another String object) unless it is final.
And just because a String instance is immutable doesn't mean that you can't make another String that derives its value from that first String instance but is slightly different.
In fact that's the only way how you can "modify" strings in Java: you can't change the content of any given String object, but you can create a copy that has modified content (that copy is then again immutable!).
Strings are immutable, meaning that this is always true:
String s = "PROJECT";
String s2 = s.toLowerCase();
System.out.println(s.equals("PROJECT")); // Prints true
System.out.println(s.equals(s2)); // Prints false
In comparison, consider what would happen if Strings were mutable.
MutableString ms = "PROJECT";
MutableString ms2 = ms.toLowerCase();
System.out.println(ms.equals("PROJECT")); // Prints false
System.out.println(ms.equals(ms2)); // Prints true
This example may seem trivial, but it means that unless you actually re-assign the reference s then you can guarantee that s will not be changed by any piece of code.
This question already has answers here:
Closed 13 years ago.
Duplicate
java String concatenation
I'm curious what is the difference between the two.
The way I understand the string pool is this:
This creates 3 string objects in the string pool, for 2 of those all references are lost.
String mystr = "str";
mystr += "end";
Doesn't this also create 3 objects in the string pool?
String mystr = "str";
mystr = mystr.concat("end")
I know StringBuilder and StringBuffer are much more efficient in terms of memory usage when there's lots of concatination to be done. I'm just curious if there's any difference between the + operator and concat in terms of memory usage.
There's no difference in this particular case; however, they're not the same in general.
str1 += str2 is equivalent to doing the following:
str1 = new StringBuilder().append(str1).append(str2).toString();
To prove this to yourself, just make a simple method that takes two strings and +='s the first string to the second, then examine the disassembled bytecode.
By contrast, str1.concat(str2) simply makes a new string that's the concatenation of str1 and str2, which is less expensive for a small number of concatenated strings (but will lose to the first approach with a larger number).
Additionally, if str1 is null, notice that str1.concat(str2) throws a NPE, but str1 += str2 will simply treat str1 as if it were null without throwing an exception. (That is, it yields "null" concatenated with the value of str2. If str2 were, say, "foo", you would wind up with "nullfoo".)
Update: See this StackOverflow question, which is almost identical.
The important difference between += and concat() is not performance, it's semantics. concat() will only accept a string argument, but + (or +=) will accept anything. If the non-string operand is an object, it will be converted to a string by calling toString() on it; a primitive will be converted as if by calling the appropriate method in the associated wrapper class, e.g., Integer.toString(theInt); and a null reference becomes the string "null".
Actually, I don't know why concat() even exists. People see it listed in the API docs and assume it's there for a good reason--performance being the most obvious reason. But that's a red herring; if performance is really a concern, you should be using a StringBuilder, as discussed in the thread John linked to. Otherwise, + or += is much more convenient.
EDIT: As for the issue of "creating objects in the string pool," I think you're misunderstanding what the string pool is. At run-time, the actual character sequences, "str" and "end" will be stored in a dedicated data structure, and wherever you see the literals "str" and "end" in the source code, the bytecode will really contain references to the appropriate entries in that data structure.
In fact, the string pool is populated when the classes are loaded, not when the code containing the string literals is run. That means each of your snippets only creates one object: the result of the concatenation. (There's also some object creation behind the scenes, which is a little different for each of the techniques, but the performance impact is not worth worrying about.)
The way I understand the string pool
is this:
You seem to have a misconception concerning that term. There is no such thing as a "string pool" - the way you're using it, it looks like you just mean all String object on the heap. There is a runtime constant pool which contains, among many other things, compile-time String constants and String instances returned from String.intern()
Unless the argument to concat is an empty string, then
String mystr = "str";
mystr = mystr.concat("end")
will also create 3 strings.
More info: https://docs.oracle.com/javase/1.5.0/docs/api/java/lang/String.html.