[JAVA] Rock Paper Scissors!

[iago]

Also, I thought you couldn't compare Java strings with "==" operator, or was I wrong about that? 

You're right, although it wouldn't give you a compile error, it won't work when you run the program.

According to what Kp posted, it works fine.  *shrug*

Maybe it's a newer feature in like 1.5-style compilers?  I learned on 1.4 compilers, so..

[dxoigmn]

You're right, although it wouldn't give you a compile error, it won't work when you run the program.

Yep. Kp's example is misleading.

Code Select Expand


[dxoigmn@tahoe:~]# cat Test.java
public class Test {
    public static void main(String[] args) {
        String a = "abc";
        String b = "a";

        b += "b";
        b += "c";

        System.out.println(a + " == " + b + " => " + (a == b));
    }
}
[dxoigmn@tahoe:~]# gcj --main=Test Test.java
[dxoigmn@tahoe:~]# ./a.out
abc == abc => false


[Falcon[anti-yL]]

Also, I thought you couldn't compare Java strings with "==" operator, or was I wrong about that? 

You're right, although it wouldn't give you a compile error, it won't work when you run the program.

According to what Kp posted, it works fine.  *shrug*

Maybe it's a newer feature in like 1.5-style compilers?  I learned on 1.4 compilers, so..

We use 1.5 at our school and I was working on a program when I figured it out. I had to use equals() to make it work.

[FrOzeN]

Erm, it's not a dice. You don't exactly 'roll' scissors or paper, though I guess you can with rocks.

I noticed that, but I realized that if I posted something petty like that, people might stop caring about things I say. so I'd better not. 

Point taken, though Joe know's I'm just joking around.

[The-FooL]

== compares references.  If the objects that the strings point to are the same, then it will return true.  More likely is that both strings contain the same data, but are different objects in memory, so the comparison will return false.

[iago]

== compares references.  If the objects that the strings point to are the same, then it will return true.  More likely is that both strings contain the same data, but are different objects in memory, so the comparison will return false.

That's what I thought, but Kp's example seemed to show otherwise..

[K]

== compares references. If the objects that the strings point to are the same, then it will return true. More likely is that both strings contain the same data, but are different objects in memory, so the comparison will return false.

That's what I thought, but Kp's example seemed to show otherwise..

Take a look at dx's example.  I think Kp's is showing the same behavior as this C snippet:

Code Select Expand


const char* a = "abc";
const char* b = "abc";

if (a == b)
{
   // ...
}


which will return true as the compiler will assign both pointers to point to the same memory.  In java this probably happens also because strings are immutable; if you change a, it won't change  b, but rather b will point to a new string.

dx's example shows that two strings with the same contents but that point to different objects should return false.

[iago]

But Kp's strings clearly aren't the same, since he constructs them in different ways.  Does Java really search for strings that are the same and combine them?  That seems really bad, and it seems like it could lead to a lot of confusion... :-/

[MyndFyre]

But Kp's strings clearly aren't the same, since he constructs them in different ways.  Does Java really search for strings that are the same and combine them?  That seems really bad, and it seems like it could lead to a lot of confusion... :-/

Kp's strings really aren't constructed differently.  Look at the code:

Code Select Expand


String a = "abc";
String b = "def";
String c = "abc";
String d = "a" + "b" + "c";

The Java compiler recognizes that "a" + "b" + "c" is a constant expression and concatenates them at compile time to reduce memory use and runtime operations.  I believe Java also uses string interning (like .NET) to reduce the number of times a specific string exists in memory.  Thus, if "abc" is loaded three times at compile time, since Java strings are immutable, the variables a, c, and d can all safely point to the same string in memory.

However, doing this:

Code Select Expand


String a = "a";
a = a + "b";
a = a + "c";
// or
a = "a";
a = a.concat("b");
a = a.concat("c");

will both result in a being a different string reference than the String abc = "abc" declaration would.

[iago]

Ah, I get it. 

I still think that's evil, though.  If it's going to work like that, it should just error out if you compare strings with ==..

[MyndFyre]

Ah, I get it. 

I still think that's evil, though.  If it's going to work like that, it should just error out if you compare strings with ==..

It's in the Java API that you're not supposed to compare strings with ==.  It's the same with every object comparison in Java -- you compare object references.  You don't do this:

Code Select Expand


public class Blarg
{
  private int i;
  Blarg a = new Blarg();
  Blarg b = new Blarg();
  a = 1;
  b = 1;
  System.out.println(a==b);
}

Strings are just another Object-derived class; why would you expect it to work with String and not Blarg?

[iago]

Ah, I get it. 

I still think that's evil, though.  If it's going to work like that, it should just error out if you compare strings with ==..

It's in the Java API that you're not supposed to compare strings with ==.  It's the same with every object comparison in Java -- you compare object references.  You don't do this:

Code Select Expand


public class Blarg
{
  private int i;
  Blarg a = new Blarg();
  Blarg b = new Blarg();
  a = 1;
  b = 1;
  System.out.println(a==b);
}

Strings are just another Object-derived class; why would you expect it to work with String and not Blarg?

I wouldn't expect it to worth with string, of course.  I also wouldn't expect the following strings:

String a = "abc";
String b = "a" + "b" + "c";

to be equal, for the same reason I wouldn't expect your Blargs to be equal. 

I totally agree that you shouldn't compare objects with '==', but the way String's are handled seems to make it look like you can. 

[MyndFyre]

I totally agree that you shouldn't compare objects with '==', but the way String's are handled seems to make it look like you can. 

That's only because of the hack of overloading the + operator.  If Java supports overloaded operators in one class, then it should support them in all classes (of course, then it'd be C#).

Like I said before, the fact that "abc" == "a" + "b" + "c" is a compile-time optimization.  If you did something like:

Code Select Expand


String abc = "abc";
String def = "a";
def = def.concat("b");
def = def.concat("c");
System.out.println(abc==def);


The compiler most likely won't optimize this out (although in theory it could since it's really only operating on constants... but you'd have to have a really smart compiler).

I still think that the way strings are native to Java should make them either an intrinsic data type or at least also overload == to call .equals().  But that's just me.  I'm not sure if there's an equivalent to .ReferenceEquals in Java, and if not, it would be impossible to do the current implementation of ==.

[iago]

I totally agree that you shouldn't compare objects with '==', but the way String's are handled seems to make it look like you can. 

That's only because of the hack of overloading the + operator.  If Java supports overloaded operators in one class, then it should support them in all classes (of course, then it'd be C#).

Like I said before, the fact that "abc" == "a" + "b" + "c" is a compile-time optimization.  If you did something like:

Code Select Expand


String abc = "abc";
String def = "a";
def = def.concat("b");
def = def.concat("c");
System.out.println(abc==def);


The compiler most likely won't optimize this out (although in theory it could since it's really only operating on constants... but you'd have to have a really smart compiler).

I still think that the way strings are native to Java should make them either an intrinsic data type or at least also overload == to call .equals().  But that's just me.  I'm not sure if there's an equivalent to .ReferenceEquals in Java, and if not, it would be impossible to do the current implementation of ==.

You're completely right.  But optimizations should be 100% invisible from the point of view of the programer.  This isn't really invisible, though, it does affect ==.  So it shouldn't be optimized like that, in my opinion. 

[Kp]

Alternately, they could've avoided this whole mess if they'd had a, c, d share the underlying data, but be three distinct String objects (each with a distinct address).  This would add another layer of indirection (and inefficiency), but Java advocates have a long history of accepting inefficiency and poor performance to uphold their language of choice.

Thus, == would only return true if you were truly comparing a reference to itself, not just comparing one String reference to another String reference (which by chance happened to have the same internal text and the optimizer proved this at compile time).  equals() is for deep comparisons.  == shouldn't be affected by the presence of a string-folding optimizer.