0

I tried comparing two strings with .equals() method as well as with equals sign(==). But sometimes, both of them give same answer. How do I resolve this?

kosa
  • 65,990
  • 13
  • 130
  • 167
Ashima
  • 129
  • 1
  • 11
  • 8
    just don't compare Strings with == – Marco Forberg Jun 21 '13 at 19:13
  • What's wrong with it? – Grzegorz Piwowarek Jun 21 '13 at 19:15
  • even when i want to compare reference equality, the answer should not be same. But why do I get same answer? – Ashima Jun 21 '13 at 19:17
  • 2
    Comparing any two objects with `==` compares to see if they are THE EXACT SAME object. Using `.equals` (when supported) compares to see if the objects have the same value. (And, obviously, if two objects compare equal with `==` they will be equal with `.equals`.) – Hot Licks Jun 21 '13 at 19:17
  • If you get `true` from an `==` compare of two object references that means that the references are to the exact same object. This can happen accidentally or intentionally with String objects, depending on how they were created and handled. – Hot Licks Jun 21 '13 at 19:18
  • IIRC, static strings are created on stack, and JVM is smart enough to reference same string from same address. `String a = "foo";` `String b = "foo"` then `a == b` will be `true`. – jnovacho Jun 21 '13 at 19:23
  • (It should be pointed out that this question is a dupe -- the same question appears about monthly.) – Hot Licks Jun 21 '13 at 19:24
  • @jnovacho = If they were "created on stack" they would not be `==` equal. – Hot Licks Jun 21 '13 at 19:24
  • @pivovarit sorry i should have added "unless you really want to check if it is exactly the same reference" – Marco Forberg Jun 21 '13 at 19:31
  • Duplicate : http://stackoverflow.com/questions/513832/how-do-i-compare-strings-in-java/513839 – happybuddha Jun 21 '13 at 19:44
  • From the question I seem to understand you expect the strings to be different. It would be so much clearer if you could post a concrete example explaining what do you expect and what is behaviour you want to "solve". – madth3 Jun 21 '13 at 22:56

1 Answers1

4

There are basically two things to know about interned strings:

There are a couple of finer points though:

  • Concatenation of compile time constant strings is also a compile time constant, so for example the result of "foo"+"bar" is the (interned) constant String "foobar".
  • The intern() method interns a copy, which it returns. The original string is not added to the "interned string pool".
  • Interned strings cannot be garbage collected. If you intern strings that you don't actually use you are leaking memory.
Joni
  • 108,737
  • 14
  • 143
  • 193
  • is there something like automatic string interning? – Ashima Jun 21 '13 at 19:19
  • @Ashima - Literal Strings are automatically interned. And Strings returned from many JDK methods such as Class.getName() will be automatically interned. – Hot Licks Jun 21 '13 at 19:22
  • 1
    Interned strings should be garbage collected, although they weren't in, Java 1.1ish. – Tom Hawtin - tackline Jun 21 '13 at 19:33
  • @TomHawtin-tackline - That's interesting, do you have a reference for that? – Joni Jun 21 '13 at 19:39
  • @Joni - They are hard to GC. I would not be surprised that they weren't in 1.1, since classes were not GCed, nor were several other things. – Hot Licks Jun 21 '13 at 20:00
  • @HotLicks They're "hard" to GC because they are (or were, things in this area have changed about recently) in the permanent generation. Because that generation largely contains code, it doesn't get GCed very often, unless you go around loading lots of code from different class loaders or creating interned strings (so don't do that). – Tom Hawtin - tackline Jun 21 '13 at 20:27
  • @TomHawtin-tackline - No, they're hard to GC because they're hard to GC. There are some fairly complicated race conditions that can occur if you GC an interned string (or a class), and those needed to be accounted for. In the early Sun JVMs there were several such functions "commented out" because they couldn't make them work reliably. – Hot Licks Jun 21 '13 at 20:48
  • @HotLicks I don't follow you. Are (were) they often pinned? Otherwise they're just some memory in the Java heap. – Tom Hawtin - tackline Jun 22 '13 at 21:20
  • @TomHawtin-tackline - The problem is maintaining the semantic, given all the possible concurrency scenarios, including GC getting into the act. I don't recall the specifics, but it took us several weeks of puzzling over it to get it to be bulletproof and also efficient. Remember, a big part of it is maintaining a directory of interned strings (and doing so atomically and without any chance of duplicate entries). – Hot Licks Jun 22 '13 at 23:33