aspose file tools*
The moose likes Beginning Java and the fly likes equality operator still confuses me... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "equality operator still confuses me..." Watch "equality operator still confuses me..." New topic
Author

equality operator still confuses me...

Avander Be
Greenhorn

Joined: Oct 16, 2007
Posts: 16
Hi campers,

Heading for D-Day and still not getting all subtilities of the == operator...



This results in:


Strings are objects and since there's no assignment, just a method call on the strings, so I thought we're just comparing two different String references here, resulting in two 'Not Equal' outputting. Where's the catch?

TIA


Steve Jobs: "Nobody uses Java anymore" ( Who the f*ck is Steve Jobs?)
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3548
    
  15
My guess would be that there is an optimisation in the substring method that returns the original string if the index is zero, but you would have to look at the source code to confirm this.


Joanne
Mladen Grabowsky
Greenhorn

Joined: Sep 19, 2007
Posts: 29
You'll have a hard time figuring out the differences of equals and == in Java by trial and error, since the compiler is optimizing a lot as soon as it finds a string literal.

Compile you test, then decomile it using JAD/FrontEnd Plus, to see what really happens

In short:
== compares references, while equals() compares the contents of two strings.
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3548
    
  15
Originally posted by Joanne Neal:
My guess would be that there is an optimisation in the substring method that returns the original string if the index is zero, but you would have to look at the source code to confirm this.


Just looked at the source code and I was right
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3548
    
  15
Having said that though, this is just Sun's implementation of the method. Unless the Java Language Specification explicitly says this should be done, it may be different in other JVMs (or even other versions of Sun's JVM), so you probably shouldn't rely on it.
Avander Be
Greenhorn

Joined: Oct 16, 2007
Posts: 16
Many thanks for the fast answers.

I do realize that one should not use == to compare strings, I just came accross this code in some mock exams and went completely haywire at answering them ( there where a whole bunch of them b*st*rds!).

So I was just curious to know how I could predict the result, just in case I meet that sort of question on D-day...

My rule of thumb was that this type of comparison should always turn false 'cause basically it compares the content of two independent string references. Hmm, not so independent after all, I guess that there's only one "String' string on the string pool and the JVM handed out the same reference twice??
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19695
    
  20

Well, ususally not (unless using intern() and constants). However, the String class has several optimizations that return the string itself when the operation would return an equal string. trim(), substring(), toLowercase(), toUppercase(), most methods won't create a new object if it's not necessary.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Avander Be
Greenhorn

Joined: Oct 16, 2007
Posts: 16
So you really have to dive in the String methods code to be sure...
Adam Schaible
Ranch Hand

Joined: Oct 04, 2007
Posts: 101
Each string literal is a reference (�4.3) to an instance (�4.3.1, �12.5) of class
String (�4.3.3). String objects have a constant value. 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.

15.28 Constant Expression

A compile-time constant expression is an expression denoting a value of
primitive type or a String that does not complete abruptly and is composed
using only the following:
� Literals of primitive type and literals of type String (�3.10.5)
� Casts to primitive types and casts to type String
� The unary operators +, -, ~, and ! (but not ++ or --)
� The multiplicative operators *, /, and %
� The additive operators + and -
� The shift operators <<, >>, and >>>
� The relational operators <, <=, >, and >= (but not instanceof)
� The equality operators == and !=
� The bitwise and logical operators &, ^, and |
� The conditional-and operator && and the conditional-or operator ||
� The ternary conditional operator ? :
� Parenthesized expressions whose contained expression is a constant expression.
� Simple names that refer to constant variables (�4.12.4).
� Qualified names of the form TypeName . Identifier that refer to constant variables
(�4.12.4).
Compile-time constant expressions are used in case labels in switch statements
(�14.11) and have a special significance for assignment conversion (�5.2).

Compile- time constants of type String are always �interned� so as to share unique instances, using the method String.intern.
A compile-time constant expression is always treated as FP-strict (�15.4),
even if it occurs in a context where a non-constant expression would not be considered
to be FP-strict.
Examples of constant expressions:
true
(short)(1*2*3*4*5*6)
Integer.MAX_VALUE / 2
2.0 * Math.PI
"The integer " + Long.MAX_VALUE + " is mighty big."


So if a String is interned, then all literal value's point to the same string in memory - so the first "String" is created, the substring method returns this. The method basically says "String" == "String". It wouldn't change from JVM to JVM (according to the JLS) but if the source changed it might.
Joanne Neal
Rancher

Joined: Aug 05, 2005
Posts: 3548
    
  15
Just to avoid any possible confusion, the results the OP is seeing are not actually anything to do with use of literal strings. The same results would occur using variables.
Rob Spoor
Sheriff

Joined: Oct 27, 2005
Posts: 19695
    
  20

Originally posted by Avander Be:
So you really have to dive in the String methods code to be sure...

Or just always assume the method may return a new object and always use equals.

equals will still return true if they are the same object, because x.equals(x) should return true for all objects x.
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2416
    
    7

The best way to figure the difference between == operator and equals() method is to try out some code. In general == tests the values for primitives and references for objects, while equals() method tests the content of objects.

For strings, capitalized letters are different from non-capitalized letters. Eg "String" is not the same as "string". Below says its all.



You may want to test the code out with primitive wrapper classes (Integer, Double, Boolean etc).


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: equality operator still confuses me...