Comment 1 Dani Megert 2019-01-09 12:33:50 EST

(In reply to Lars Vogel from comment #0)
> Looks to me that org.eclipse.jface.util.Util#hashCode can be replaced by
> Objects.hashCode.

Which one of these:
hashCode(int)
hashCode(Object)
hashCode(Object[])
?

Note that there are several copies of Util in the SDK.

Comment 2 Julian Honnen 2019-01-10 02:43:23 EST

(In reply to Dani Megert from comment #1)

hashCode(int)      -> Integer#hashCode (or just inline it)
hashCode(Object)   -> Objects#hashCode
hashCode(Object[]) -> Objects#hash

Comment 3 Dani Megert 2019-01-10 08:45:38 EST

(In reply to Julian Honnen from comment #2)
> hashCode(Object[]) -> Objects#hash

Yes, it is not specified in Javadoc, but it would definitely be a change in the implementation.

Comment 4 Julian Honnen 2019-01-10 10:37:11 EST

(In reply to Dani Megert from comment #3)
> Yes, it is not specified in Javadoc, but it would definitely be a change in
> the implementation.

True. Is the implementation expected to be stable? Or would a note in the deprecation comment be enough for the (few?) users that rely on that specific implementation?

Comment 5 Dani Megert 2019-01-10 11:53:39 EST

(In reply to Julian Honnen from comment #4)
> (In reply to Dani Megert from comment #3)
> > Yes, it is not specified in Javadoc, but it would definitely be a change in
> > the implementation.
> 
> True. Is the implementation expected to be stable? Or would a note in the
> deprecation comment be enough for the (few?)

"few?" - that's the question. Do you know?

Comment 6 Lars Vogel 2019-01-11 02:49:06 EST

(In reply to Dani Megert from comment #5)
> "few?" - that's the question. Do you know?

Julian, I think what Dani means is that with OS you never know who is using it.


Implementation of a method is not expected to be stable, as long as the new hashcodes are correct, we should be fine.

Comment 7 Julian Honnen 2019-01-11 06:53:32 EST

(In reply to Dani Megert from comment #5)
> "few?" - that's the question. Do you know?

No, that's just a guess.

(In reply to Lars Vogel from comment #6)
> Implementation of a method is not expected to be stable, as long as the new
> hashcodes are correct, we should be fine.

There's not really a "correct" implementation of hashCode (as long as it's deterministic), but Objects#hash does return different results than Util.

Java has some classes where the hashCode implementation is specified (e.g. String), but for any other class I would consider it a bug to rely on an implementation.

Comment 8 Lars Vogel 2019-01-11 07:02:07 EST

(In reply to Julian Honnen from comment #7)

> Java has some classes where the hashCode implementation is specified (e.g.
> String), but for any other class I would consider it a bug to rely on an
> implementation.

+1

Comment 9 Jose Probst 2019-07-09 10:47:32 EDT

The mentioned methods were already marked as deprecated during https://bugs.eclipse.org/bugs/show_bug.cgi?id=546994
only hashCode(Object) is still used once.
should I open a gerrit which replaces this?

Comment 10 Lars Vogel 2019-07-09 11:20:10 EDT

(In reply to Jose Probst from comment #9)
> The mentioned methods were already marked as deprecated during
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=546994
> only hashCode(Object) is still used once.
> should I open a gerrit which replaces this?

+1

Comment 11 Eclipse Genie 2019-07-10 03:24:50 EDT

New Gerrit change created: https://git.eclipse.org/r/145761

Comment 12 Eclipse Genie 2019-08-19 04:32:37 EDT

Gerrit change https://git.eclipse.org/r/145761 was merged to [master].
Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=72d00c42d5f74fd1d3fd45e5150b4326dad40fa2

Comment 13 Lars Vogel 2019-08-19 04:32:42 EDT

Thanks, Jose.