Same type checking and array types and containsTypeEquivalent question

[Maurizio Cimadamore]

Hi Laird,
Thanks for reaching out.

The use of containsTypeEquivalent in that location is likely a leftover. 
Remember that javac was developed _while_ the specification for generics 
and wildcards was written. I recall that ~20 years ago, javac used to 
allow wildcards in a lot more places compared to the spec (and this 
caused several issues). That's probably why this method was needed back 
then.

All our regressions tests seems to be fine without the call (as you 
correctly predicted), so we should probably get rid of it.

Filed this:

https://bugs.openjdk.org/browse/JDK-8374910

For now I've assigned to Vicente, but if you want to take a stab at it, 
we'd be happy to accept your contribution!

Cheers
Maurizio


On 07/01/2026 23:41, Laird Nelson wrote:
> I had a question about a particular branch of "same type" checking in 
> the compiler.
>
> In TypeEqualityVisitor, when it is testing for "same typeness" with 
> regard to array types 
> <https://github.com/openjdk/jdk/blob/jdk-27%2B3/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L1430-L1440>, 
> it does the following:
>
> return s.hasTag(ARRAY)
>                     && containsTypeEquivalent(t.elemtype, elemtype(s));
>
> So if (t is an array type and) s is an array type and t's element type 
> contains a type that is equivalent to s's element type, then t and s 
> are in this case deemed to be the same.
>
> (containsTypeEquivalent tests to see if t and s are the same type or 
> contain each other 
> <https://github.com/openjdk/jdk/blob/jdk-27%2B3/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L4623-L4626>.)
>
> I'm surprised by the use of containsTypeEquivalent here, since it 
> seems to me that the only way in which it could do anything 
> interesting in this usage beyond applying a "same type" test is if it 
> were possible for an array type's element type to be a wildcard. But 
> this is impossible, so containsTypeEquivalent, when called from this 
> location with these arguments, would seem to always devolve to a 
> simple "same type" check, since containsType devolves to a "same type" 
> test 
> <https://github.com/openjdk/jdk/blob/jdk-27%2B3/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L1575> 
> in the presence of non-wildcard arguments.
>
> After a brief conversation, Dan Smith suggested I write here and see 
> if TypeEqualityVisitor's visitArrayType method needs to be refactored, 
> or if there's some edge case I'm not seeing (entirely possible), 
> perhaps around error cases and such, that requires this usage of 
> containsTypeEquivalent in the array type code path.
>
> Happy new year,
> Laird
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20260109/54ba1896/attachment-0001.htm>