Is "String s = "abc";" equal to "String s = new String("abc");"?

Discussion in 'Java' started by Bruce Sam, Nov 18, 2004.

  1. Bruce Sam

    Bruce Sam Guest

    In my opinion,"String s = "abc";" has only created a reference s not a
    object."String s= new String("abc");" has created a new object and its
    reference is s.Is it right?If I'm right,I still have a question.When I
    can use first one not need the second one?
     
    Bruce Sam, Nov 18, 2004
    #1
    1. Advertising

  2. Bruce Sam wrote:

    > In my opinion,"String s = "abc";" has only created a reference s not a
    > object."String s= new String("abc");" has created a new object and its
    > reference is s.Is it right?


    Not really. Both declare a reference, and while the first doesn't
    explicitly *create* an object at runtime, there still *is* an Object.
    It's part of the constant pool of the class and created when the
    class is loaded.
     
    Michael Borgwardt, Nov 18, 2004
    #2
    1. Advertising

  3. Bruce Sam

    kaeli Guest

    In article <>,
    enlightened us with...
    > In my opinion,"String s = "abc";" has only created a reference s not a
    > object."String s= new String("abc");" has created a new object and its
    > reference is s.Is it right?If I'm right,I still have a question.When I
    > can use first one not need the second one?
    >
    >


    It is my understanding that if you don't specify the "new" keyword, if
    another string object already has a reference to the value "abc", a new
    object is not created (no more memory is allocated) - instead, it points to
    the same spot in memory. If nothing does, it does create a new object (memory
    allocation). If you specify the new keyword, a new object is always created
    (memory allocation), regardless.
    Mostly the difference is seen with the equals method and '=='.

    See this page for a better explanation:
    http://www.jchq.net/certkey/0502certkey.htm

    --
    --
    ~kaeli~
    You feel stuck with your debt if you can't budge it.
    http://www.ipwebdesign.net/wildAtHeart
    http://www.ipwebdesign.net/kaelisSpace
     
    kaeli, Nov 18, 2004
    #3
  4. Bruce Sam

    Chris Smith Guest

    kaeli <> wrote:
    > It is my understanding that if you don't specify the "new" keyword, if
    > another string object already has a reference to the value "abc", a new
    > object is not created (no more memory is allocated)


    It's a little different than that. There is a pool of String objects
    maintained by the JVM. Some String objects are in that pool, and others
    are not. When you say:

    String a = "abc";

    then the JVM arranges for "abc" to be in that pool, and then produces a
    reference to it when executing that code. When you write:

    String a = new String("abc");

    then the JVM still arranges for "abc" to be in that pool, and still
    provides a reference to it, but that reference is then passed into a
    constructor to create a NEW String object that's NOT in the pool and
    copies the first one. It's that second String object which ends up
    being assigned to the reference.

    This is different from your statement above. If a String object exists
    that contains the same contents -- abc -- but the object is NOT in the
    pool (if, for example, it was read from a file or database), then the
    literal "abc" will resolve to a new String object that's different from
    that existing one.

    It's also a little imprecise to says that the pooled String objects are
    created by the code above. Instead, it's better to say that the code
    above ensures that at some point, the JVM will arrange for the String
    object to have been created when that code executes. However, that
    object will be created only once, regardless of how many times the code
    is executed, or even how many times the literal "abc" appears in the
    code.


    > Mostly the difference is seen with the equals method and '=='.
    >


    Yes. Use of '==' is, in fact, the only direct way to see the
    difference. Indirectly, of course, you could observe the memory usage
    of the application after a large number of repetitions of the code.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Nov 18, 2004
    #4
  5. "Michael Borgwardt" <> wrote in message
    news:...
    > Bruce Sam wrote:
    >
    >> In my opinion,"String s = "abc";" has only created a reference s not a
    >> object."String s= new String("abc");" has created a new object and its
    >> reference is s.Is it right?

    >
    > Not really. Both declare a reference, and while the first doesn't
    > explicitly *create* an object at runtime, there still *is* an Object.
    > It's part of the constant pool of the class and created when the
    > class is loaded.


    The second creates two objects, since the constant String "abc" and the
    results of "new String()" must be distinct.
     
    Mike Schilling, Nov 18, 2004
    #5
  6. "Chris Smith" <> wrote in message
    news:...
    >
    > Yes. Use of '==' is, in fact, the only direct way to see the
    > difference. Indirectly, of course, you could observe the memory usage
    > of the application after a large number of repetitions of the code.


    At an intermediate level of directness, you could create a thread that locks
    "abc" and observe that a different thread can lock the new-ed String.
     
    Mike Schilling, Nov 19, 2004
    #6
  7. Mike Schilling wrote:
    >>Not really. Both declare a reference, and while the first doesn't
    >>explicitly *create* an object at runtime, there still *is* an Object.
    >>It's part of the constant pool of the class and created when the
    >>class is loaded.

    >
    >
    > The second creates two objects, since the constant String "abc" and the
    > results of "new String()" must be distinct.


    But the literal isn't created when the line is executed, it's created when
    the class is loaded.
     
    Michael Borgwardt, Nov 19, 2004
    #7
  8. Bruce Sam

    Tony Morris Guest

    "Mike Schilling" <> wrote in message
    news:c09nd.23033$...
    >
    > "Michael Borgwardt" <> wrote in message
    > news:...
    > > Bruce Sam wrote:
    > >
    > >> In my opinion,"String s = "abc";" has only created a reference s not a
    > >> object."String s= new String("abc");" has created a new object and its
    > >> reference is s.Is it right?

    > >
    > > Not really. Both declare a reference, and while the first doesn't
    > > explicitly *create* an object at runtime,


    This is incorrect.
    A String literal involves the runtime creation of an object.
    In fact, two of the same String literals that are in different scopes may
    create have separate objects created.
    Here's the challenge for the reader: prove this beyond doubt (it can be
    done).

    > there still *is* an Object.
    > > It's part of the constant pool of the class and created when the
    > > class is loaded.

    >


    The 'constant pool' is an abstract concept that should not be thought of as
    a physical thing - it simply does not physically exist.

    > The second creates two objects, since the constant String "abc" and the
    > results of "new String()" must be distinct.
    >


    Specifically, the object created by the new operator must not exist anywhere
    else at that time.

    --
    Tony Morris
    http://xdweb.net/~dibblego/
     
    Tony Morris, Nov 19, 2004
    #8
  9. Bruce Sam

    Tony Morris Guest

    "Michael Borgwardt" <> wrote in message
    news:...
    > Mike Schilling wrote:
    > >>Not really. Both declare a reference, and while the first doesn't
    > >>explicitly *create* an object at runtime, there still *is* an Object.
    > >>It's part of the constant pool of the class and created when the
    > >>class is loaded.

    > >
    > >
    > > The second creates two objects, since the constant String "abc" and the
    > > results of "new String()" must be distinct.

    >
    > But the literal isn't created when the line is executed, it's created when
    > the class is loaded.


    The literal, being a constant (JLS 15.28), is "created" at compile-time.
    The object that is used is created at runtime.

    --
    Tony Morris
    http://xdweb.net/~dibblego/
     
    Tony Morris, Nov 19, 2004
    #9
  10. Tony Morris wrote:
    >>>>Not really. Both declare a reference, and while the first doesn't
    >>>>explicitly *create* an object at runtime, there still *is* an Object.
    >>>>It's part of the constant pool of the class and created when the
    >>>>class is loaded.
    >>>
    >>>
    >>>The second creates two objects, since the constant String "abc" and the
    >>>results of "new String()" must be distinct.

    >>
    >>But the literal isn't created when the line is executed, it's created when
    >>the class is loaded.

    >
    >
    > The literal, being a constant (JLS 15.28), is "created" at compile-time.


    Actually, at the time the source code is written.

    > The object that is used is created at runtime.


    I meant "the object represented by the literal".
     
    Michael Borgwardt, Nov 19, 2004
    #10
  11. Tony Morris wrote:
    >>>>In my opinion,"String s = "abc";" has only created a reference s not a
    >>>>object."String s= new String("abc");" has created a new object and its
    >>>>reference is s.Is it right?
    >>>
    >>>Not really. Both declare a reference, and while the first doesn't
    >>>explicitly *create* an object at runtime,

    >
    >
    > This is incorrect.
    > A String literal involves the runtime creation of an object.


    Thus, "explicitly".

    > In fact, two of the same String literals that are in different scopes may
    > create have separate objects created.
    > Here's the challenge for the reader: prove this beyond doubt (it can be
    > done).


    Actually, I can prove beyond doubt that it's incorrect. The JLS section 3.10.5 says:

    -----------------------
    # Literal strings within the same class (§8) in the same package (§7)
    represent references to the same String object (§4.3.1).
    # Literal strings within different classes in the same package represent references
    to the same String object.
    # Literal strings within different classes in different packages likewise
    represent references to the same String object.
    -----------------------


    >>>It's part of the constant pool of the class and created when the
    >>>class is loaded.

    >>

    >
    > The 'constant pool' is an abstract concept that should not be thought of as
    > a physical thing - it simply does not physically exist.


    The Java Virtual Machine Specification disagrees:

    -----------------------
    4.1 The ClassFile Structure

    A class file consists of a single ClassFile structure:


    ClassFile {
    u4 magic;
    u2 minor_version;
    u2 major_version;
    u2 constant_pool_count;
    cp_info constant_pool[constant_pool_count-1]; <----------------------
    u2 access_flags;
    u2 this_class;
    u2 super_class;
    u2 interfaces_count;
    u2 interfaces[interfaces_count];
    u2 fields_count;
    field_info fields[fields_count];
    u2 methods_count;
    method_info methods[methods_count];
    u2 attributes_count;
    attribute_info attributes[attributes_count];
    }
    -----------------------

    Unless you define files in general as "non-physical".
     
    Michael Borgwardt, Nov 19, 2004
    #11
  12. Bruce Sam

    Tony Morris Guest

    "Michael Borgwardt" <> wrote in message
    news:...
    Tony Morris wrote:
    >>>>In my opinion,"String s = "abc";" has only created a reference s not a
    >>>>object."String s= new String("abc");" has created a new object and its
    >>>>reference is s.Is it right?
    >>>
    >>>Not really. Both declare a reference, and while the first doesn't
    >>>explicitly *create* an object at runtime,

    >
    >
    > This is incorrect.
    > A String literal involves the runtime creation of an object.


    Thus, "explicitly".

    > In fact, two of the same String literals that are in different scopes may
    > create have separate objects created.
    > Here's the challenge for the reader: prove this beyond doubt (it can be
    > done).


    Actually, I can prove beyond doubt that it's incorrect. The JLS section
    3.10.5 says:

    -----------------------
    # Literal strings within the same class (§8) in the same package (§7)
    represent references to the same String object (§4.3.1).
    # Literal strings within different classes in the same package represent
    references
    to the same String object.
    # Literal strings within different classes in different packages likewise
    represent references to the same String object.
    -----------------------



    This is (yet another) an ambiguity in the JLS.
    The challenge remains - it can be proven, without a doubt.

    --
    Tony Morris
    http://xdweb.net/~dibblego/
     
    Tony Morris, Nov 19, 2004
    #12
  13. Tony Morris wrote:
    > "Michael Borgwardt" <> wrote in message
    > news:...
    > Tony Morris wrote:
    >
    >>In fact, two of the same String literals that are in different scopes may
    >>create have separate objects created.
    >>Here's the challenge for the reader: prove this beyond doubt (it can be
    >>done).

    >
    >
    > Actually, I can prove beyond doubt that it's incorrect. The JLS section
    > 3.10.5 says:
    >
    > -----------------------
    > # Literal strings within the same class (§8) in the same package (§7)
    > represent references to the same String object (§4.3.1).
    > # Literal strings within different classes in the same package represent
    > references
    > to the same String object.
    > # Literal strings within different classes in different packages likewise
    > represent references to the same String object.
    > -----------------------
    >
    >
    >
    > This is (yet another) an ambiguity in the JLS.
    > The challenge remains - it can be proven, without a doubt.


    The ambiguity, I suppose, being a question of time. The JLS is
    ambiguous about whether those invariants are required to hold for any
    two strings chosen at any two points during program execution, or
    whether it only applies to program state any particular time. The
    observable behavior of Sun's recent implementations of the String intern
    pool is that otherwise unreferenced Strings are eventually discarded.
    Thus if I write

    public class StringTest {
    static void printHashOne() {
    // Print identity hash for locally-scoped "abc"
    System.out.print("Identity hashcode 1: ");
    System.out.println("abc".identityHashCode());
    }
    static void printHashTwo() {
    // Print identity hash for locally-scoped "abc"
    System.out.print("Identity hashcode 2: ");
    System.out.println("abc".identityHashCode());
    }
    static void doSomethingElse() {
    /* implementation left as an exercise to the reader */
    }
    public static void main(String[] args) {
    printHashOne();
    doSomethingElse();
    printHashTwo();
    }
    }

    then it is possible that the two identity hashes printed by one run of
    the program will be different. (It depends on how long doSomethingElse()
    runs, how many GC cycles take place, whether or not doSomethingElse
    references an equal String literal or other equal interned String,
    etc.). The doSomethingElse() method can be implemented in a way that
    pretty reliably exhibits the different object identities for "abc" on
    Sun's 1.3 and 1.4 VMs.


    John Bollinger
     
    John C. Bollinger, Nov 19, 2004
    #13
  14. "Michael Borgwardt" <> wrote in message
    news:...
    > Mike Schilling wrote:
    >>>Not really. Both declare a reference, and while the first doesn't
    >>>explicitly *create* an object at runtime, there still *is* an Object.
    >>>It's part of the constant pool of the class and created when the
    >>>class is loaded.

    >>
    >>
    >> The second creates two objects, since the constant String "abc" and the
    >> results of "new String()" must be distinct.

    >
    > But the literal isn't created when the line is executed, it's created when
    > the class is loaded.


    Quibble accepted. But the second form does create a String that the first
    does not.
     
    Mike Schilling, Nov 19, 2004
    #14
  15. John C. Bollinger wrote:
    >> -----------------------
    >> # Literal strings within the same class (§8) in the same package (§7)
    >> represent references to the same String object (§4.3.1).
    >> # Literal strings within different classes in the same package represent
    >> references
    >> to the same String object.
    >> # Literal strings within different classes in different packages likewise
    >> represent references to the same String object.
    >> -----------------------
    >>
    >>
    >>
    >> This is (yet another) an ambiguity in the JLS.
    >> The challenge remains - it can be proven, without a doubt.

    >
    >
    > The ambiguity, I suppose, being a question of time. The JLS is
    > ambiguous about whether those invariants are required to hold for any
    > two strings chosen at any two points during program execution, or
    > whether it only applies to program state any particular time. The


    Ah, this issue:
    http://www.javaworld.com/javaworld/javaqa/2003-12/01-qa-1212-intern.html


    > observable behavior of Sun's recent implementations of the String intern
    > pool is that otherwise unreferenced Strings are eventually discarded.
    > Thus if I write
    >
    > public class StringTest {
    > static void printHashOne() {
    > // Print identity hash for locally-scoped "abc"
    > System.out.print("Identity hashcode 1: ");
    > System.out.println("abc".identityHashCode());
    > }
    > static void printHashTwo() {
    > // Print identity hash for locally-scoped "abc"
    > System.out.print("Identity hashcode 2: ");
    > System.out.println("abc".identityHashCode());
    > }
    > static void doSomethingElse() {
    > /* implementation left as an exercise to the reader */
    > }
    > public static void main(String[] args) {
    > printHashOne();
    > doSomethingElse();
    > printHashTwo();
    > }
    > }
    >
    > then it is possible that the two identity hashes printed by one run of
    > the program will be different.


    Only when the class has bean unloaded inbetween and loaded again. That's
    rather more than the "different scopes" that Tony said were required.
     
    Michael Borgwardt, Nov 19, 2004
    #15
  16. Michael Borgwardt wrote:

    > John C. Bollinger wrote:
    >> The ambiguity, I suppose, being a question of time. The JLS is
    >> ambiguous about whether those invariants are required to hold for any
    >> two strings chosen at any two points during program execution, or
    >> whether it only applies to program state any particular time. The

    >
    >
    > Ah, this issue:
    > http://www.javaworld.com/javaworld/javaqa/2003-12/01-qa-1212-intern.html


    Yep, that's it.


    >> then it is possible that the two identity hashes printed by one run of
    >> the program will be different.

    >
    >
    > Only when the class has bean unloaded inbetween and loaded again. That's
    > rather more than the "different scopes" that Tony said were required.


    Yes, you're right, and so my example was oversimplified for the case of
    String literals. And as you say, "different scopes" is not a sufficient
    condition for literals, although it _is_ sufficient for interned Strings
    not representing a literal in any currently loaded class.


    John Bollinger
     
    John C. Bollinger, Nov 19, 2004
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jiong Feng
    Replies:
    0
    Views:
    837
    Jiong Feng
    Nov 19, 2003
  2. Colin Peters

    Special character to &abc equivalents

    Colin Peters, May 7, 2005, in forum: ASP .Net
    Replies:
    8
    Views:
    2,302
    =?Utf-8?B?UGF1bCBQYXJraW5zb24=?=
    May 9, 2005
  3. vsgdp

    ABC inheriting from ABC

    vsgdp, Sep 24, 2005, in forum: C++
    Replies:
    1
    Views:
    312
    vsgdp
    Sep 24, 2005
  4. Gunter Henriksen

    x.abc vs x['abc']

    Gunter Henriksen, May 13, 2009, in forum: Python
    Replies:
    1
    Views:
    357
    alex23
    May 15, 2009
  5. Replies:
    4
    Views:
    154
Loading...

Share This Page