JDK-8162803 : investigate type containment, type equality and their relationship
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2016-07-29
  • Updated: 2018-01-24
  • Resolved: 2018-01-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorResolved
Related Reports
Duplicate :  
Relates :  
Description
Currently Types.SameTypeVisitor.visitClassType has the following code:

...
return t.tsym == s.tsym
                    && visit(t.getEnclosingType(), s.getEnclosingType())
                    && containsTypes(t.getTypeArguments(), s.getTypeArguments());

check if after the fix for JDK-8159970 type equality don't need to be expressed in terms of type containment. I realize that this code is the way it is partially because of the existence of two same type visitors: loose and strict and the use of the loose visitor by the containment visitor, via subtype visitor. So the first step should be to remove, if possible, all invocations of the loose visitor that can be fulfilled by the strict visitor. If this is possible, then the remaining use cases needing the loose visitor should be investigated and then probably it could make sense to move some / all of it's code to other visitors.
Comments
This investigation led to JDK-8196074; closing this bug - please refer to JDK-8196074 from now on.
24-01-2018