Bug 549116 - [impl] clean-up reference binding equality
Summary: [impl] clean-up reference binding equality
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.13   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-09 13:47 EDT by Stephan Herrmann CLA
Modified: 2022-10-14 08:31 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Herrmann CLA 2019-07-09 13:47:30 EDT
In the olden days, ReferenceBindings could safely be compared with ==, and only ReferenceBinding.hashCode() contained a tweak to enable replacing a URB with a resolved binding without re-hashing (see the comment still visible in RB.hashCode()).


With the advent of type annotations (JSR 308) differently annotated references to the same type have different instances of RB, connected to the one an only prototype of each. From this point on every use of == needs an explicit excuse documented with //$IDENTITY-COMPARISON$. Every other comparison must go through TypeBinding.equalsEquals().


Bug 544921 introduced ReferenceBindingSetWrapper, which allows to create sets that bypass both contracts:
- a URB and its resolved binding will be treated as different types
- an annotated type and its prototype will be treated as different types.

I'm not saying that storing ReferenceBindings in sets (or ObjectVector) was fully safe before bug 544921, but the current state surely looks inconsistent.

One thing to research in git history: why was TypeBinding.equalsEquals() made a static method, rather than overriding the member method equals() in TypeBinding?
Comment 1 Stephan Herrmann CLA 2019-07-09 13:56:32 EDT
Also, what is the relationship between TypeSystem.HashedParameterizedTypes.PTBKey and the new ReferenceBindingSetWrapper?
Comment 2 Manoj N Palat CLA 2019-08-27 01:35:16 EDT
Bulk move to 4.14
Comment 3 Sebastian Zarnekow CLA 2019-09-01 16:42:12 EDT
Thanks for adding to this bug Stephan. It's still not clear to me though, what's supposed to be done here.
Comment 4 Stephan Herrmann CLA 2019-11-17 16:08:36 EST
Bulk move of unassigned bugs to 4.15
Comment 5 Stephan Herrmann CLA 2020-02-27 18:50:11 EST
Bulk move to 4.16
Comment 6 Stephan Herrmann CLA 2020-05-18 18:45:58 EDT
Bulk move of unassigned bugs to 4.17
Comment 7 Eclipse Genie CLA 2022-10-14 08:31:35 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.