keyword "new"

[Higgledy Smith]

In String g = new String("spot"); Keyword new creates a String object in non-pool memory.

As opposed to String g = "spot"; Defaults to create the String constant pool memory.

Are String objects the only wrappers that use a pool memory scheme by default?

Example:
Integer x = new Integer(3);
-OR-
SomeObject banana = new SomeObject();
What purpose is "new" serving in the above two lines?

Thanks,
Phil

[Mark Spritzler]

Yes the String Pool is only created for Strings, and there is only the String Pool, and there isn't an Integer pool, etc.

Mark

[Higgledy Smith]

so the "new" in any other non-String object is creating a new object in normal memory. Correct?

[Tamara Lopez]

and for string objects. new creates objects in the heap for all types, including String. When you dont use "new" with String it creates it in the String pool.

[Krishnamoorthy Sethuraman]

As per what I read in k&b book, even integers less than 128 are stored in the constant pool automatically when the JVM starts. Following code illustrates the same:

public static void main(String... args)
{
Integer i1 = 127;
Integer i2 = 127;
if(i1  == i2)
System.out.println("i1 and i2 are same objects");
i1 = 128;
i2= 128;
if(i1  == i2)
System.out.println("i1 and i2 are same objects");
else
System.out.println("i1 and i2 are different objects");
}    

Output of above code is :
i1 and i2 are same objects
i1 and i2 are different objects.
Holds good only for integer constants and not for objects created using new operator.

[Higgledy Smith]

But wouldn't i2 be equal to i1 after i2 is set to 128? Since i1 is already equal to 128.

i1 = 128;
i2= 128;

[Higgledy Smith]

Also, with autoboxing. Suppose I want the value of the reference variable not that value of the object. How do I get this value?

System.out.println(i2); In 5.0 this displays int value 127. In 1.4 this displayed the value of the ref variable.

[Tad Dicks]

what seems strange (to me at least)
after doing this:

public static void compare(Object o, Object oo)
    {
        if (o == oo)
            System.out.println("o and oo are same objects");
        else
            System.out.println("o and oo are different objects");
    }
    public static void main(String... args)
{
Integer i1 = 128;
Integer i2 = 128;
                compare(i1, i2);
i1 = 128;
i2= 128;
                compare(i1, i2);
                String f = "foo";
                String x = "foo";
                compare(f, x);
f = new String("foo");
                x= new String("foo");
                compare(f,x);
}     

The out put is:
o and oo are different objects
o and oo are different objects
o and oo are same objects
o and oo are different objects

I would have expected the same results from your code.. but merely passing them to a method caused them to get their own references?

-Tad

[Ernest Friedman-Hill]

I've taken it as my personal mission lately to try to make people understand that the String pool is not a special area of memory. String literals, like all Strings and all other objects, are in the Java heap. The String pool is a set of unique String references, used to avoid making duplicate copies of literals. Picture it like a HashSet<String> . The Strings are not in the pool -- just references to them are.

[Jim Yingst]

[EFH]: Picture it like a HashSet<String>

Or WeakHashSet<String>, if such a thing existed. But anyone familiar with WeakHashMap ought to be able to infer what I mean, even though Sun didn't deign to fill that particular niche for us. Oh well, no big deal.

More to the point, I'd also want to remind people that you WILL NOT get questions on the actual SCJP exam that depend on understnading of the string pool. You may see mock exams that (inadvertently) deal with it, but if you are at all confused, and if you're just interested in passing the exam, you should probably just ignore such questions.

On the other hand, if you want to discuss the string pool further, regardless of the SCJP, Java in General (Intermediate) would be a good place. It's a complex issue, and many SCJP candidates seem to be better off not worrying about it. Additionally it's pretty rare that this issue is important for working programmers. Usually you just use equals() rather than ==, and it doesn't matter whether a given string has been pooled or not.

I fully approve of anyone wishing to understand this issue better, but the SCJP forum is not the best place for it.
[ March 10, 2006: Message edited by: Jim Yingst ]