Home arrow static arrow Java Programming [Archive] - getSource()
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - getSource()
This topic has 11 replies on 1 page.

Posts:41
Registered: 4/21/02
getSource()  
Aug 2, 2004 6:06 AM



 
When using getSource() is it better to use equals() or ==. I did it both ways and they both worked. I learned that I am suppose to use equals() with Objects and since getSource() returns an Object, I would think that I would use equals(), but, every example that I have seen uses ==.

public void actionPerformed(ActionEvent e) {      if(e.getSource().equals(aButton)) {                System.out.println(�Button Pressed�);      }} OR public void actionPerformed(ActionEvent e) {       if(e.getSource() == aButton) {                System.out.println(�Button Pressed�);       }}
 

Posts:569
Registered: 8/8/01
Re: getSource()  
Aug 2, 2004 6:14 AM (reply 1 of 11)



 
Currently this is just for convinience. Maybe some implementations will change in nearby future and then "==" will not work appropriate any longer!

So do what you have learned and use equals(Object o)

regards
 

Posts:3,055
Registered: 18/06/98
Re: getSource()  
Aug 2, 2004 6:19 AM (reply 2 of 11)



 
It would be better to use "equals", but "==" does the job as well in the specific case of comparing the result of getSource().
If your JVM is smart enough, there will be almost no runtime difference between "equals" and "==" in the case of EventSources.
 

Posts:3,055
Registered: 18/06/98
Re: getSource()  
Aug 2, 2004 6:20 AM (reply 3 of 11)



 
So keep using "equals", to protect yourself against some quirkness that can happen when some other class defines "getSource".
 

Posts:1,872
Registered: 2/12/03
Re: getSource()  
Aug 2, 2004 6:35 AM (reply 4 of 11)



 
as my understanding goes "==" check on references

so

Object obj = event.getSource();
if (button1 == obj) ..then it's actually check the reference. if the object points to the same address..then it's the same object

if you overide the equals(0 method ... this could result in the same object as being nt equals (depends on how the equals was overide)

example

Class Red extends MyColor{    String color = "red"    public boolean equals(Object o){        MyColor c = (MyColor) o;        return (o.getColor().equals("rouge");      }} class Rouge extends MyColor{    String color ="rouge";    public boolean equals(Object o){        MyColor c = (MyColor) o;        return (o.getColor().equals("red");      }} now    MyColor red = new Red();   MyColor rouge = new Rouge();   Object o = event.getSource();   // o is "Red"   if (o.equals(red);   // not equal ..even though it's the same object


even though this is rare..but you must make sure the equals(0 method doesn't do anything weird

i would use "==" operator
and it's unlikely that they will change this operator.

actually, i would use getActionCommand()
this has the advantages of separating the controller from the view
 

Posts:5,965
Registered: 5/17/03
Re: getSource()  
Aug 2, 2004 6:44 AM (reply 5 of 11)



 
So do what you have learned and use equals(Object o)

I'm not so sure. GetSource returns a reference of class Object and this should be compared to the reference of aButton to establish if this is the source of the action. The reference of aButton has been registred previously especially for this purpose. In this case two references clearly are to be compared and then == is appropriate. Equals will work in this case because unless it has been overridden it uses == too.

Equals should be used when an object has overriden equals for the purpose of using its content (value) for comparision. This is the case for example with String and Integer. But it's not the case here because what's important is the unique identity of the objects and not their contents. So use ==. It's also slightly faster than equals.

Well I see I'm in minority now but maybe some more people come in and vote -:)
 

Posts:447
Registered: 3/8/01
Re: getSource()  
Aug 2, 2004 6:47 AM (reply 6 of 11)



 
Using == is fine. The getSource() method is defined to return the object which caused the event to occur, not some object equal to it. The reason equals() works is that, by default, Object.equals is defined to use == itself, and JButton does not override this.
 

Posts:569
Registered: 8/8/01
Re: getSource()  
Aug 2, 2004 7:12 AM (reply 7 of 11)



 
Object.equals is defined to use == itself, and JButton does not override this

Correct, but think about it will be decided, to get more consistence into all of the JDK, and equals will be overriden in JButton, then "==" will not work correctly any longer
 

Posts:192
Registered: 30/05/01
Re: getSource()  
Aug 2, 2004 7:13 AM (reply 8 of 11)



 
I always use ==

EventObject.getSource() returns an Object.

api docs for Object.equals() states -

"...The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any reference values x and y, this method returns true if and only if x and y refer to the same object (x==y has the value true)...."

...so maybe that implies that it doesn't matter which you use (as far as getSource() is concerned). if you haven't overidden equals(Object o)...

When overriding equals(Object o) - the first thing that is generally done is to use the == operator to check if the argument is a reference to this object (returning true if it is). This is just a performance optimisation, but one that is worth doing if the comparison is potentially expensive. - see Bloch[Effective Java Programming Language Guide 2001 p33].

So does that imply that even when equals is overidden, it still doesn't matter whether we use == or equals (as far as getSource() is concerned)?

I'd still err on the side of == for (probably fairly negligible) performance reasons alone.
 

Posts:1,872
Registered: 2/12/03
Re: getSource()  
Aug 3, 2004 7:21 AM (reply 9 of 11)



 
Correct, but think about it will be decided, to get more consistence into all of the JDK, and equals will be
overriden in JButton, then "==" will not work correctly any longer

i don't see how "==" wouold not work here. if anything, it's the other way around (if the object extends JButton and overide equals(Object) method with funky comparison algorithm)

"==" will always work, since it check on references (not content of the Object)
 

Posts:5,965
Registered: 5/17/03
Re: getSource()  
Aug 3, 2004 8:08 AM (reply 10 of 11)



 
"==" will always work, since it check on references
(not content of the Object)

That's my opinion too. In this case it's the identity of the object and not its value that's of interest. The reference will always uniquely identify an object but the value wont. So == is correct and equals downright wrong.
 

Posts:27,518
Registered: 11/3/97
Re: getSource()  
Aug 3, 2004 9:25 AM (reply 11 of 11)



 
So do what you have learned and use equals(Object o)

I'm not so sure. GetSource returns a reference of
class Object and this should be compared to the
reference of aButton to establish if this is the
source of the action. The reference of aButton has
been registred previously especially for this purpose.
In this case two references clearly are to be compared
and then == is appropriate. Equals will work in this
case because unless it has been overridden it uses ==
too.

Equals should be used when an object has overriden
equals for the purpose of using its content (value)
for comparision. This is the case for example with
String and Integer. But it's not the case here because
what's important is the unique identity of the objects
and not their contents. So use ==. It's also slightly
faster than equals.

Well I see I'm in minority now but maybe some more
people come in and vote -:)

Given that I don't do GUIs, .....

Based on your above explaination the only correct solution is to use "==".

The code needs to respond to the actual source (the single one that exists in the system) and not to one that looks like it (possibly more than one.) This will always be the case. So "==" should always be used.

And even though equals() currently has the same functionality it should not be used, because as pointed out, that might not be true in some future code. So it should never be used (in this particular case of course.)
 
This topic has 11 replies on 1 page.