0

If I pass a String literal to some metohd as:

String s=new String("stack"); String s2=s.concat("overflow");

where string "overflow" will be stored.

one of my friends arguing that it is created in String constant pool and I'm opposing him.

please let me know

Thanks in advance.

Improve this question
2
  • 2
    Why are you opposing him? It's a string constant. Commented Feb 10, 2014 at 11:43
  • 2
    The "where are strings created" and "where are parameters stored" aspects of this question have mostly separate answers. The parameter passing mechanism operates the same on Strings and other objects, but depending on the JVM, String literals may or may not be allocated in a special manner. Commented Feb 10, 2014 at 11:43

3 Answers 3

Reset to default
3

All String literals go in the constant pool. The End. In this case, two constants, "stack" and "overflow", go into the pool. A new String is created that holds the same value as the "stack" in the pool, and then another String is created by concatenating the "overflow" from the constant pool to it.

Excerpt from javap -c -verbose Test:

Constant pool: #1 = Methodref #10.#19 // java/lang/Object."<init>":()V #2 = Class #20 // java/lang/String #3 = String #21 // stack #4 = Methodref #2.#22 // java/lang/String."<init>":(Ljava/lang/String;)V #5 = String #23 // overflow #6 = Methodref #2.#24 // java/lang/String.concat:(Ljava/lang/String;)Ljava/lang/String;
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Relevant section of the JLS: docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.10.5 - "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."
@davmac I actually compiled this code because I wasn't sure whether this would be a compile-time constant ("stack" + "overflow" is), and it was easier than digging through the JLS.
that's fine. I already upvoted your answer. I added the JLS reference as a comment so it's there if anyone wants it.
@davmac Always happy to have a citation. Just not motivated enough to provide it myself right now. ;-)
0

This question is certainly undecidable, yet you can find out how a certain combination of java compiler and JVM does it.

As far as I can see, nothing could stop one from writing a java compiler that, when it sees a string constant, emits byte code to create that string in the heap in some way as long as the rules stated in the JLS concerning string literals are still maintained. For example, String.intern could maintain a global Map, and the compiler could compile a String literal like follows:

create a char array of the desired size put character at index 0 put character at index 1 ... put character at index (length-1) construct the actual string object pass the String just created to String.intern and leave result on the stack

Actually, one could have a pre-processor changing all string constants to

(extra.HeapString.createString(new char[] { ... }))

and have createString create a String instance in such a way that the rules for String literals hold. And you couldn't write a program that could detect if it was compiled from the original source or from the preprocessed one (except through reflection on extra.HeapString).

Improve this answer

16 Comments

Opposing string pool and heap is misleading: the string pool may be stored on the main heap (for example it is the case on hotspot since Java 7).
This behavior is explicitly specified in the JLS. You could write a compiler that breaks the rules in all sorts of ways, but it wouldn't be a correct Java compiler.
@chrylis that's what I meant.
@chrylis Version? Paragraph? Page?
@Ingo your argument is flawed. Whether or not string literals generate objects on the heap or not does not affect the answer to the question (which is about whether string literals are in the "String constant pool"). The effect of requiring that string literals be intern'd (JLS 3.10.5) is that there is a pool of String constants, and it is mandated by the JLS that String literals yield Strings from this pool.
|
-1

The string stack will be in the heap, the string overflow is in the constant pool, the third string as the result of concatenation stackoverflow in the constant pool.

Improve this answer

2 Comments

Mostly wrong, right, wrong. stack is in the constant pool, overflow is in the constant pool, and stackoverflow is on the heap. The constant pool may be on the heap at the discretion of the JVM author. stackoverflow won't go into the pool unless it's explicitly interned.
"stack" the literal will be in the constant pool but s will refer to a copy of it which will be on the heap (due to new String(...)).

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.