Summary: | Deprecate org.eclipse.jface.util.Util#hashCode in favor of Objects.hashCode | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Lars Vogel <Lars.Vogel> |
Component: | UI | Assignee: | Jose Probst <josef.j.probst> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | daniel_megert, josef.j.probst, julian.honnen, Lars.Vogel |
Version: | 4.10 | Keywords: | bugday, helpwanted |
Target Milestone: | 4.13 M3 | ||
Hardware: | PC | ||
OS: | Windows 10 | ||
See Also: |
https://git.eclipse.org/r/145761 https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=72d00c42d5f74fd1d3fd45e5150b4326dad40fa2 |
||
Whiteboard: |
Description
Lars Vogel
2019-01-09 04:27:17 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. (In reply to Dani Megert from comment #1) hashCode(int) -> Integer#hashCode (or just inline it) hashCode(Object) -> Objects#hashCode hashCode(Object[]) -> Objects#hash (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. (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? (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? (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. (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. (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 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? (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 New Gerrit change created: https://git.eclipse.org/r/145761 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 Thanks, Jose. |