<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Laird,<br>
Thanks for reaching out.</p>
<p>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.</p>
<p>All our regressions tests seems to be fine without the call (as
you correctly predicted), so we should probably get rid of it.</p>
<p>Filed this:</p>
<p><a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8374910">https://bugs.openjdk.org/browse/JDK-8374910</a></p>
<p>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!</p>
<p>Cheers<br>
Maurizio<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 07/01/2026 23:41, Laird Nelson
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAHNdxu=WTk2+=F0T_inOnhrrmcU=tJLnK4o7YV9tX8JmFaozQw@mail.gmail.com">
<div dir="ltr">
<div>I had a question about a particular branch of "same type"
checking in the compiler.</div>
<div><br>
</div>
<div>In <a href="https://github.com/openjdk/jdk/blob/jdk-27%2B3/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L1430-L1440" moz-do-not-send="true"><span style="font-family:monospace">TypeEqualityVisitor</span>,
when it is testing for "same typeness" with regard to array
types</a>, it does the following:</div>
<div><br>
</div>
<div style="margin-left:40px"><span style="font-family:monospace">return s.hasTag(ARRAY)<br>
&&
containsTypeEquivalent(t.elemtype, elemtype(s));</span></div>
<div><br>
</div>
<div>So if (<span style="font-family:monospace">t</span> is an
array type and) <span style="font-family:monospace">s</span>
is an array type and <span style="font-family:monospace">t</span>'s
element type contains a type that is equivalent to <span style="font-family:monospace">s</span>'s element type, then
<span style="font-family:monospace">t</span> and <span style="font-family:monospace">s</span> are in this case
deemed to be the same.</div>
<div><br>
</div>
<div>(<span style="font-family:monospace">containsTypeEquivalent</span>
tests to see if <span style="font-family:monospace">t</span>
and <span style="font-family:monospace">s</span> <a href="https://github.com/openjdk/jdk/blob/jdk-27%2B3/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L4623-L4626" moz-do-not-send="true">are the same type or contain each
other</a>.)</div>
<div><br>
</div>
<div>I'm surprised by the use of <span style="font-family:monospace">containsTypeEquivalent</span>
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 <span style="font-family:monospace">containsTypeEquivalent</span>,
when called from this location with these arguments, would
seem to always devolve to a simple "same type" check, since <span style="font-family:monospace">containsType</span> <a href="https://github.com/openjdk/jdk/blob/jdk-27%2B3/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java#L1575" moz-do-not-send="true">devolves to a "same type" test</a> in
the presence of non-wildcard arguments.</div>
<div><br>
</div>
<div>After a brief conversation, Dan Smith suggested I write
here and see if <span style="font-family:monospace">TypeEqualityVisitor</span>'s
<span style="font-family:monospace">visitArrayType</span>
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 <span style="font-family:monospace">containsTypeEquivalent</span>
in the array type code path.</div>
<div><br>
</div>
<div>Happy new year,</div>
<div>Laird</div>
<div><br>
</div>
<div><br>
</div>
</div>
</blockquote>
</body>
</html>