Skip to main content

Add === operator for a.equals(b).

59 replies [Last post]
laurapiersol
Offline
Joined: 2003-06-13
Points: 0

Add === operator that maps for primitives to == and maps for classes to:

(a == b || (a != null && a.equals(b))

Would make code much cleaner and clearer without changing JVM or having compatibility issues.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwenting
Offline
Joined: 2003-12-02
Points: 0

instanceof is an operator...

monika_krug
Offline
Joined: 2004-10-14
Points: 0

Alternative notation that also prevents mistyping from ==:
Use ~ instead of ===.

Monika.

jarouch
Offline
Joined: 2004-03-04
Points: 0

Nice;) Or <-> , <=> as equivalency operator may be good.

monika_krug
Offline
Joined: 2004-10-14
Points: 0

Might be, but <=> and <-> are used in mathematics with boolean expressions on both sides.

If it weren't for the mistyping issue I'd prefer ===.

Monika.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Your're driving me crazy with all those operators :-)
What about // ? :-P

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> Your're driving me crazy with all those operators
> :-)
> What about // ? :-P

I'd say we get rid of java.lang.Math and replace it with the much simpler APL notation ;)

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

[b]ATTENTION. This idea seem brilliant to me and deserves special attention. I am just afraid it gets lost here in this === related bla bla bla.

Would you mind opening dedicated discussion for this?[/b]

patrikbeno
Offline
Joined: 2004-10-11
Points: 0
draccagni
Offline
Joined: 2003-06-15
Points: 0

Regarding ==, equals() I think that they have to be leaved as they are : very special meaning ... what I suggest is operator overloading for =, +, - ... operators.
We have it for String at the end, from Tiger also for
Integer, Double, ... . Why don't we have it for any class ?

D.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

We do not have operator overloading capability. We have some explicitly defined overloading mechanism for String (and it is specified in JLS). As for Integer, Double, etc. this is not operator overloading, this is auto(un)boxing which seems similar but is different.

As you see, it is all a little confusing. Do you suggest extend the level of confusion? No thank you.

Feasible solution is somthing called "operator functions"
http://forums.java.net/jive/thread.jspa?threadID=132&tstart=0

draccagni
Offline
Joined: 2003-06-15
Points: 0

Sorry, but it doesn't seem the same, it is FORMALLY the same !!! also if you call it auto(un)boxing. The way the String are managed is the only aspect that I don't appreciate about Java : + is overloaded, String is class, but the only class with an overloaded operator. Now FORMALLY it is possible also with Integer, Double ... : auto(un)boxing it just a way to justify it.

Anyway, I think that operator function is A GREAT IDEA.
I VOTE FOR IT : + 100 ;-)

D.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

If you like operator function proposal, you probably should express your support in linked discussion :-) Do it :-)

draccagni
Offline
Joined: 2003-06-15
Points: 0

Done ! :-)

laurapiersol
Offline
Joined: 2003-06-13
Points: 0

Thanks for the non-official response from SUN.

I disagree with your reasoning though. If I understand correctly there doesn't seem to be an agreement on what the semantics of '===' should be or even whether it should be the '===' operator. Valid point, but as the band "Rush" would say "you still have made a choice". Just because SUN can't make a decision doesn't mean a decision isn't being made everyday by users (and usually the most inexperienced users). Look at the forall loop. Did you NOT implement it because the 'best' syntax couldn't be agreed upon? No, you picked a syntax and went with it. Same here. I don't care what the syntax or meaning is just as long as there is one! You picked best practices for method and class naming so code is universally readable so do the same here.

The second point is the language is getting polluted by all this stuff being added to it. I don't believe "FIXING" an inconsistency in the language (Object and Primitive equality) can be considered polluting the language. Maybe I'm wrong but I'd bet a rather large sum of money that given 100 new programmers and 100 experienced programmers, both groups would make a lot less programming mistakes with my syntax and would declare the language and there code much clearer too. I could be wrong so I won't push the point.

Thanks again for the unofficial response from SUN and for every one else who added to the debate.

laurapiersol
Offline
Joined: 2003-06-13
Points: 0

I don't mean to give offence to anyone but I respectfully must say there seems to be a lot of NOISE going on here without any real technical discussion. I haven't agreed with all the decisions SUN has made with the Java language (generics) but at least I've understood their decisions. I'm not sure after 50 messages I understand either the technical or architectural issues with this proposal.

To force focus once again let me recap.

Reasons for:
1.) NO CHANGE to JVM. Backwards compatible.
2.) Simplifies syntax of language (easier to READ and learn). More terse without being cryptic.
3.) Reduces common errors in code such as NullArgumentException (and don't pretend that isn't a common one).
4.) Merges Object and Primitive syntax. "===" works the same for both Objects and Primitives. "==" doesn't work the same for both (Compare primitive wrappers).
Example:
new Integer(301) == new Integer(301) // Not true.
301 == 301 // true.

Reasons against:
1.) "===" looks to much like "==". Will confuse readers. I agree 100%. Lets change syntax to something SUN would agree with (ex: <=>).
2.) This is operator overloading and operator overloading is bad. I agree overloading is bad but lets remember why its bad and what were actually doing here. Overloading is bad because users start creating cryptic meanings for operators and the programs logic becomes unintelligible. This isn't the case here because "equals" is a method of the base Object. It is already used for many things like HashMap and such. You aren't OVERLOADING anything here, merely creating SYNTACTIC sugar. HashMap wouldn't start working any different. You can't change the meaning of a program with this (unlike overloading "==" which would change the meaning of a program).
3.) Should just use MACROS and maybe static import. Reasonable reason but I respectfully disagree. Maybe everything should be a MACRO in the language but if Theresa just ONE THING that shouldn't be a MACRO its the comparison operator (===). Actually it's probable the def operator '='. However '+', '-', and '*' better be MACROS before '===' is a MACRO.

I'ld loved to here SUN's opinion on this proposal (good, bad, or otherwise). Just admitting they don't have the time or people would be good enough for me. We all have priorities and I respect that.

peterkessler
Offline
Joined: 2004-10-27
Points: 0

I'm certainly not anything like an official position from Sun on this issue, but I can try to convince the folks who are to take a look at it.

I don't do language design, but historically we've had enough confusion between "=" and "==" that introducing a third variant "===" seems misguided.

I'd certainly want to try this out with a library method for a while to make sure we have the right semantics. I can imagine that though you want
[pre]
(a == b || (a != null && a.equals(b))
[/pre]
there will be other people who want to know that not only are a and b equal, but also that neither is null. E.g.,
[pre]
((a != null) && (b != null) && ((a == b) || a.equals(b)))
[/pre]
Is that an unreasonable semantics for "==="? I'm sure there are other variants, all of which will be someone's favorite. And why should Object.equals(Object) get all the attention? Why not "<==" for
[pre]
((a != null) && ((a instanceof Comparable) && ((Comparable) a).compareTo(b) < 0))
[/pre]
I'm sure I wouldn't want to sprinkle that all over my code! And so on for other comparisons.

We try to avoid slippery slopes like that. That's why there are methods: so you can write your own.

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> I'm certainly not anything like an official position
> from Sun on this issue, but I can try to convince the
> folks who are to take a look at it.
>
> I don't do language design, but historically we've
> had enough confusion between "=" and "==" that
> introducing a third variant "===" seems misguided.

I agree that this (and a number of the other suggestions) seem misguided. I was hoping that this one would die on the vine ;)

jwenting
Offline
Joined: 2003-12-02
Points: 0

> > I'm certainly not anything like an official
> position
> > from Sun on this issue, but I can try to convince
> the
> > folks who are to take a look at it.
> >
> > I don't do language design, but historically we've
> > had enough confusion between "=" and "==" that
> > introducing a third variant "===" seems misguided.
>
> I agree that this (and a number of the other
> suggestions) seem misguided. I was hoping that this
> one would die on the vine ;)

I just wish people would stop askjing for tons and tons of changes to the core language.
If there's one way to destroy the usefulness of Java it's by making it too large, too cumbersome to learn and use.

Instead the core language should be stripped to be as small as possible and the standard API handle the rest.
And that too should be lean and mean, if you want some shortcut to achieve something you can always make it yourself but don't try to force your ideals of yet another alternative syntax onto the world.

yishai
Offline
Joined: 2003-11-16
Points: 0

> I just wish people would stop askjing for tons and
> tons of changes to the core language.
> If there's one way to destroy the usefulness of Java
> it's by making it too large, too cumbersome to learn
> and use.

I don't think people are asking for tons and tons, but different people ask for different things, so it looks that way.

> Instead the core language should be stripped to be as
> small as possible and the standard API handle the
> rest.

So if we were voting on having a >= b to save the a > b || a == b coding, what would your vote be? Would it keep the language simpler to leave it out? In an ideal world where backward compatability was a non-issue, would you vote to remove >= ? I'm seriously asking. I am trying to get a handle on your feeling of where the line is, and why it is there.

I honestly don't see a great difference between the API and the language. Unintuitive operators are problematic, as an API can be more expressive. But other than that, a core API is as much a part of the language, for all practical purposes.

I agree about === as it is too easy to confuse with ==. But why are adding intuitive operators so bad?

> And that too should be lean and mean, if you want
> some shortcut to achieve something you can always
> make it yourself but don't try to force your ideals
> of yet another alternative syntax onto the world.

I think when you have 1000's of programmers recreating the same shortcut, over and over and over again, it is time to look to the language.

jwenting
Offline
Joined: 2003-12-02
Points: 0

> > I just wish people would stop askjing for tons and
> > tons of changes to the core language.
> > If there's one way to destroy the usefulness of
> Java
> > it's by making it too large, too cumbersome to
> learn
> > and use.
>
> I don't think people are asking for tons and tons,
> but different people ask for different things, so it
> looks that way.
>
It amounts to the same thing.
And if you look closely the number of people asking for all these things is actually very small.

> > Instead the core language should be stripped to be
> as
> > small as possible and the standard API handle the
> > rest.
>
> So if we were voting on having a >= b to save the a >
> b || a == b coding, what would your vote be? Would it
> keep the language simpler to leave it out? In an
> ideal world where backward compatability was a
> non-issue, would you vote to remove >= ? I'm
> seriously asking. I am trying to get a handle on your
> feeling of where the line is, and why it is there.
>
If it weren't in the language already I'd not vote to have it added.

> I honestly don't see a great difference between the
> API and the language. Unintuitive operators are
> problematic, as an API can be more expressive. But
> other than that, a core API is as much a part of the
> language, for all practical purposes.
>
It is, which is why the core API should be treated like the language and not be changed unless with extreme caution.

> I agree about === as it is too easy to confuse with
> ==. But why are adding intuitive operators so bad?
>
What's intuitive to one person is not so to another.
And a wild growth of new operators (which would quickly result, also see another thread where someone wants to turn if (x == y) into an operator...) would be the inevitable result.

> > And that too should be lean and mean, if you want
> > some shortcut to achieve something you can always
> > make it yourself but don't try to force your
> ideals
> > of yet another alternative syntax onto the world.
>
> I think when you have 1000's of programmers
> recreating the same shortcut, over and over and over
> again, it is time to look to the language.

No, it's time to look towards turning the stuff into a library.
Thousands of programmers write routines to convert numbers into strings and back yet I've not yet seen a demand to turn that into an operator.

yishai
Offline
Joined: 2003-11-16
Points: 0

> > > Instead the core language should be stripped to
> be
> > as
> > > small as possible and the standard API handle
> the
> > > rest.
> >
> > So if we were voting on having a >= b to save the a
> >
> > b || a == b coding, what would your vote be?

> If it weren't in the language already I'd not vote to
> have it added.

I think there is a difference between simplicity and poverty, and that crosses into poverty.

> > I honestly don't see a great difference between
> the
> > API and the language. Unintuitive operators are
> > problematic, as an API can be more expressive. But
> > other than that, a core API is as much a part of
> the
> > language, for all practical purposes.
> >
> It is, which is why the core API should be treated
> like the language and not be changed unless with
> extreme caution.

OK, but why prefer the change be made to the core API rather than an operator if the new operator were consistent with the other operators and intutive?

> > I agree about === as it is too easy to confuse
> with
> > ==. But why are adding intuitive operators so bad?
> >
> What's intuitive to one person is not so to another.
> And a wild growth of new operators (which would
> quickly result, also see another thread where someone
> wants to turn if (x == y) into an operator...) would
> be the inevitable result.
>
> > > And that too should be lean and mean, if you
> want
> > > some shortcut to achieve something you can
> always
> > > make it yourself but don't try to force your
> > ideals
> > > of yet another alternative syntax onto the
> world.
> >
> > I think when you have 1000's of programmers
> > recreating the same shortcut, over and over and
> over
> > again, it is time to look to the language.
>
> No, it's time to look towards turning the stuff into
> a library.
> Thousands of programmers write routines to convert
> numbers into strings and back yet I've not yet seen a
> demand to turn that into an operator.

[pre]
int var = 123;
String s= "" + var;
[/pre]

I see it all the time (although I don't like writing it). It has the advantage of being null safe.

I just don't think the argument for the status-quo is a good thing. An operator can be opposed because it is not intuitive. All addtional operators being excluded up front because someone might find them unintuitive is not a good thing.

jwenting
Offline
Joined: 2003-12-02
Points: 0

NO!

Typing === or even == is WAY too much work.
= should be used for everything from comparison to assignment to binary comparison.
The compiler should determine based on what would be proper in the code which use the user meant.

While we're at it, why not simply change the language so the compiler can decide based on just the name of the classfile the entire functionality of the class and write all the code for you?

monika_krug
Offline
Joined: 2004-10-14
Points: 0

> NO!
>
> Typing === or even == is WAY too much work.
> = should be used for everything from comparison to
> assignment to binary comparison.
> The compiler should determine based on what would be
> proper in the code which use the user meant.
>
> While we're at it, why not simply change the language
> so the compiler can decide based on just the name of
> the classfile the entire functionality of the class
> and write all the code for you?

You are so funny. Not.

Monika.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

I guess following would suffice:

java/lang/Object.java:
[code]
static public boolean equals(Object o1, Object o2) {
return (o1 != null) ? o1.equals(o2) : o1 == o2;
}

static public boolean equals(Object ... objs) {
/* ... */
}
[/code]

with static import, usage is quite easy.
And since it would be part of java.lang.Object, it would also be a part of the language

viper_wolf
Offline
Joined: 2004-06-03
Points: 0

+1 I like the idea

half my code consists of

[b]( a == b || ( a != null && b != null && a.equal( b ) ) )[/b]

If I could get a 2 or 3 character opperator to do the null pointer check for me, would make the code much easier to read.

[b]===[/b]

would be good, or stick to the 2 character model and make it something like

[b]#=[/b] or [b]$=[/b]

tsinger
Offline
Joined: 2003-06-10
Points: 0

> half my code consists of
>
> [b]( a == b || ( a != null && b != null && a.equal( b
> ) ) )[/b]

Have you ever heard about refactoring? Isn't it easy to extract a static method like this (BTW, you don't need the check for b != null):
[code]public final class CompareUtils {
public static boolean areEqual(Object obj1, Object obj2) {
return (obj1 == obj2)
|| (obj1 != null && obj1.equals(obj2));
}
}[/code]
You then could use
[code]if (CompareUtils.areEqual(a, b)) {
/* do something */
}[/code]
which is VERY easy to read and write. Why changing the [i]language[/i] if something can be solved that easily with good old methods?

Tom

monika_krug
Offline
Joined: 2004-10-14
Points: 0

Why do we have a for-loop, even though it can be easily implemented as while-loop?

Monika.

regexguy
Offline
Joined: 2003-06-20
Points: 0

There was a problem reported about the equals operation on java.net not too long ago, and perhaps this operation could be made to partially solve it.

I think this:
if(a === b) {
...
}

Should be the equivalent of this:

Class ac = a.getClass(), bc = b.getClass();
if(a != null && b != null &&
(ac.isAssignableFrom(bc) && b.equals(a)) ||
(bc.isAssignableFrom(ac) && a.equals(b)) ||
(a.equals(b) && b.equals(a))) {
...
}

This would make === a symmetric operator and would make sure that the subclass's version of the operator is the one that was used.

denismo
Offline
Joined: 2003-06-28
Points: 0

+1
I agree, something is wrong with the language if to compare two Strings you need to write "false".equals(value). Not much of a spec work, and implementation is trivial. Note sure about "===" notation, high probability of typo, but the idea is good.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

But this way we get to operator overloading. Yet again. That's bad and there's no need to explain why. Done many times before.

There's nothing wrong with equals(). It's the design - objects are considered equal if equals() says they are.

We may need some syntactic sugar. Feasible proposal is here:
http://forums.java.net/jive/thread.jspa?threadID=115#2826

Combined with static imports, should be enough.

gipak
Offline
Joined: 2004-10-11
Points: 0

I must say I like your idea very much, I recently decided that i need to override equals in some classes during one project, and typeing all the

return (a==arg.a ||(a!=null && a.equals(arg.a)) && (b==arg.b ....

was making me crazy, I'd really enjoy this made automatically. It's a great idea, but '===' seems to me would cause too much trouble with misstyping, you could be searching an hour for a bug that really was just a '==' intead of'==='. [b]How about '#='[/b] harder to type (distance on a keyboard) but also harder to misstype.

monika_krug
Offline
Joined: 2004-10-14
Points: 0

There is another reason for not using "===" ... "operator" is defined as something consisting of one or two (non-alphanumeric) characters. #= does not look as nice as ===, but it removes both the problem of mistyping and of the three characters.

Monika.

gipak
Offline
Joined: 2004-10-11
Points: 0

Well there are the crazy bit shift operators >>> >>= <<= and even >>>=, but I guess they can be odd, cause they are used rarely, I think the '===' or '#=' would become more common, definitely more common than '>>>='.

monika_krug
Offline
Joined: 2004-10-14
Points: 0

You are right, I did not think of >>> etc. The definition of operators as having one or two characters was from a Java book, not from the Java specification.

Monika.

brucechapman
Offline
Joined: 2004-03-18
Points: 0

and what about instanceof !!

monika_krug
Offline
Joined: 2004-10-14
Points: 0

What about instanceof?

Monika.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

he means instanceof is operator that does not fit the definition 'one or two (or more) special characters'

monika_krug
Offline
Joined: 2004-10-14
Points: 0

Well, that's a keyword, not an operator. E.g. it does not appear in the hierarchy of operators.

Maybe a philosophical issue.

Monika.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

maybe. and maybe not :-)

http://java.sun.com/docs/books/tutorial/java/nutsandbolts/other.html
or consider JLS:
15.20.2 Type Comparison Operator instanceof

monika_krug
Offline
Joined: 2004-10-14
Points: 0

Okay :-P

laurapiersol
Offline
Joined: 2003-06-13
Points: 0

Back to main topic: adding "===" operator to java. The three main objections to this are:

1.) "==" should override "equals()" and === should perform pointer equality test. Yes, true if language was being designed from scratch and we had no backwards compatibility issues. We NEED to be backwards compatible so overriding "==" to be something different is UNACCEPTABLE. "===" Causes NO compatibility issues so is a good candidate. However, I can see subtle errors being introduced in writing "==" by mistake when "===" was meant. Maybe new syntax like "<>" would be better and less confusing. Lets discuss.

2.) Adds entropy to system / pollutes java language. What? Language is already polluted by the difference between primitives and objects. This proposal actually reduces entropy of system by removing the necessity of dealing with primitives and objects differently for equality testing. This proposal SIMPLIFIES the language.

3.) Makes java harder to understand for beginners. Are you crazy? Makes java much EASIER to understand and write robust code. I wouldn't even teach the old "==" operator anymore (maybe even depreciate or add compiler warning). I can't think of many situations where "===" wouldn't be the preferred equality operator. Think of all the subtle bugs produces by beginners and experts alike that would be taken care of:

new Integer(5) == new Integer(5); // true
new Integer(305) == new Integer(305); // ERROR false

new Integer(5) === new Integer(5); // true
new Integer(305) === new Integer(305); // true as expect.

a = null;
a.equals(b); // ERROR!! null value exception.
a === b; // works as expected

cowwoc
Offline
Joined: 2003-08-24
Points: 0

-1

Typing '===' is almost as bad as just typing equals() to begin with.

If anything, override '==' to mean equals(). I don't claim to be well informed on this issue (so please reply to my post), when is reference equation (aka '==') absolutely necessary? Why can't we just replace '==' with equals() to begin with?

Gili

vhi
Offline
Joined: 2004-10-11
Points: 0

1. It is more efficient to compare references.
2. Object reference check guarantees that two variables are pointing to the same object. According to the contract, 'equals' method only guarantees that their content is equal. It may or may not point to the same object. The former is absolute necessity in many cases.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

From personal experience, it seems to me that equals() is used far more commonly than '=='. As such, shouldn't '==' mean equals() and isSameObject() mean what '==' used to?

Also, can you give more specific examples of when '==' is currently required. I know there are such cases, but I've never had to absolutely resort to them in application code.

Gili

tsinger
Offline
Joined: 2003-06-10
Points: 0

Strange, we compare quite always with == and very seldom with equals(Obj) or CompareUtils.areEqual(Obj, Obj).

I vote for letting it like it is. It is well-thought and clean. Everybody is free to write a utility method (maybe it can be added to the JDK, so not everybody needs to write it). This is an RFE, where it is VERY easy to work-around (as opposite to, e.g. const or design-by-contract), please don't pollute the [i]language[/i] with such stuff.

Have you ever thought about new Java users? They have to learn the differences between =, == and ===? Not that intuitive, isn't it? Much easier it is to create the mentioned utility method. Same applies for comparing objects. And here YOU can define, how null-values should be compared (e.g. null is always smaller than a reference).

Tom

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

You compare quite always with == instead of equals()?
Man, that's too bad :-(

tsinger
Offline
Joined: 2003-06-10
Points: 0

Why is that bad? We relatively often use type-safe enums and very seldom implementing the hashCode and equals methods. BTW, I did not say, we don't compare with CompareUtils.areEqual(Obj, Obj), it's just not [b]so[/b] often, that we would ask for extending the language.

Tom

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Using == you compare pointers/references instead of objects. While this is sometimes useful, I believe ths scenarion covers at most ~5% use cases. Remaining ~95% is contract of equals().

Using type-safe enum with == operator? Then you must be aware of object (de)serialization. You are able to solve this issue by implementing readResolve() but you are solving wrong problem. Correct way is implementing equals() and using it.

You don't implement equals() and hashCode()? Again, you might not need it in some cases but in general, this approach invalidates your class for use in hash tables.

My experience says I really need to implement equals() and hashCode() in ~75% of new classes (sooner or later), and best practice is to use equals() to logically compare objects unless I explicitly want to check that the two references point to the very same physical instance (which is very rarely).

I wonder, what kind of applications do you work on?

tsinger
Offline
Joined: 2003-06-10
Points: 0

> Using == you compare pointers/references instead of
> objects. While this is sometimes useful, I believe
> ths scenarion covers at most ~5% use cases. Remaining
> ~95% is contract of equals().

Maybe it depends on the applications you are writing? We write desktop applications, where data-objects are relatively seldom.

> Using type-safe enum with == operator? Then you must
> be aware of object (de)serialization. You are able to
> solve this issue by implementing readResolve() but
> you are solving wrong problem. Correct way is
> implementing equals() and using it.

We do not use Java's serialization, because it is too limited and does not support obfuscation, which is a MUST for desktop applications. Hence we can compare references without any problem by ==.

> You don't implement equals() and hashCode()? Again,
> you might not need it in some cases but in general,
> this approach invalidates your class for use in hash
> tables.

Only the key object in the hash map needs the have a meaningful hashCode/equals implementation. In 95% for us Strings and Files are enough as keys.

> My experience says I really need to implement
> equals() and hashCode() in ~75% of new classes
> (sooner or later), and best practice is to use
> equals() to logically compare objects unless I
> explicitly want to check that the two references
> point to the very same physical instance (which is
> very rarely).
>
> I wonder, what kind of applications do you work on?

See above, I guess you are developing data-centric applications, am I right?

Tom

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

I think we have a conclusion :-)

- you're desktop guy, I am server-side guy, hence we have different requirements
- using equals(), hashCode() is the right way to do things, only == seems more convenient for you and your applications
- in hash tables, only key needs to have equals/hashcode but in hash sets, everything does

Finally, I think that if you use == just because it is the easiest way for you, you should not suggest this practice to others, simply because it is not right :-)