making Sets work with a custom data-type

[S Fox]

I have a class that I made which is like a custom data-type, and I'm trying to figure out how to tell java what makes each object unique for the purposes of adding them into a Set? Right now it's just adding everything.
I wanted to compare the objects by a String "name" for deciding the set membership.

[Carey Brown]

You need to override the equals() and hashCode() methods.

[Scott Shipp]

S Fox wrote:I have a class that I made which is like a custom data-type, and I'm trying to figure out how to tell java what makes each object unique for the purposes of adding them into a Set? Right now it's just adding everything.
I wanted to compare the objects by a String "name" for deciding the set membership.

Check out the information at the below links. Hope it helps

Java Trail: Object as a Superclass

Deep Dive (with a video)

Why you must override hashCode if you override equals

Helpful Stack Overflow discussion

[S Fox]

Thanks to you both, I think I got it working. I wonder why it doesn't like having the @Override tag if I am indeed overriding a method? It tells me: "The method equals(MyClass) of type MyClass must override or implement a supertype method"

[Carey Brown]

That's because it should be
equals(Object)

[Carey Brown]

The code for equals() and hashCode() can be tricky. Post your code here when you're done so we can check it.

[S Fox]

here it is without an @Override tag, I cant add it to either one, the class just holds strings

public boolean equals(Sym s) {
	if(s == null) return false;
	if( !(s instanceof Sym) ) return false;

	Sym other = (Sym) s;
	return this.symVal == other.symVal;
}

public int hashCode() {
	return symVal.hashCode() + symProp.hashCode();
}

[Rob Spoor]

Four things:
1) As said before, the single argument to the equals method should have Object as its type, not Sym. What you've done is overload the method, not override it.
2) You can merge your check for null and the instanceof check into one, because if the argument is null then instanceof will return false for every class.
3) Since this.symVal is an object (you can call hashCode() on it), you shouldn't use == to compare them. Use this.symVal.equals(other.symVal), or if they can be null use Objects.equals(this.symVal, other.symVal).
4) You use this.symProp in your hashCode implementation. This means that if two instances have equal values for symVal but different values for symProp, the instances are equal but have different hash codes. That's not allowed. You should either add an equality check for symProp in equals, or remove the use of symProp in hashCode.

So in short:

public boolean equals(Object o) {
	if( !(o instanceof Sym) ) return false;

	Sym other = (Sym) o;
	return Objects.equals(this.symVal, other.symVal) && Objects.equals(this.symProp, other.symProp);
}

[Carey Brown]

What about the trivial case where they refer to the same object?

public boolean equals(Object o) {
    if( this == o ) return true;
	if( !(o instanceof Sym) ) return false;

	Sym other = (Sym) o;
	return Objects.equals(this.symVal, other.symVal) && Objects.equals(this.symProp, other.symProp);
}

[Stephan van Hulst]

A pointless optimization most of the time.

[S Fox]

This is way more tricky than I first realized, I think I'm starting to understand it now.
I read somewhere it's bad to have the hash not be unique enough and adding more things together helps, that's why I added the other var.
How do we know if the hash is good enough, and what happens if it's a poor hash?
How come md5/sha1/sha256 hash are very unique but the java hash isn't?

[Carey Brown]

S Fox wrote:I wanted to compare the objects by a String "name" for deciding the set membership.

You seemed to have made some design changes as this thread has progressed, I don't see "name" appearing in your equals() method. What are symVal and symProp?

public boolean equals( Object o ) {
    if( ! (o instanceof Sym) ) {
        return false;
    }
    return name.equals( ((Sym)o).name );
}

[Carey Brown]

S Fox wrote:I read somewhere it's bad to have the hash not be unique enough and adding more things together helps, that's why I added the other var.

You shouldn't add something just for the hash. Only add it if it is a meaningful part of a unique key for the object.

How do we know if the hash is good enough, and what happens if it's a poor hash?

Most implementations of hashCode() build on the hashCode() methods of other Java types, e.g. String. I trust them to be sufficient.

How come md5/sha1/sha256 hash are very unique but the java hash isn't?

These that you mention return a hash code longer than 32 bits. Java only deals with 32 bit hash codes. In addition, depending on the size of the hash table, is probably using a subset of those bits.