Possible bug with multiple generic bounds

[Vicente Romero]

Hi Nir,

On 8/20/25 16:47, Nir Lisker wrote:
> ECJ doesn't have this "bug" yet still conforms to the specs. Is it 
> possible to get javac to do the same thing here?

to start with it could be argue that it could be a bug that ECJ is 
accepting this code. But considering only the javac side, what you are 
suggesting would imply implementing non-specified behavior. Which will 
imply accepting programs that once the specification settles on this 
issue could be rejected thus having a future compatibility issue. javac 
is not supposed to accept the same universe of programs as ECJ. This is 
desirable for all users but there are differences. Sometimes due to 
bugs, sometimes because the compilers cover some gaps or gray areas that 
are under specified. IMO this case represents a gap wide enough to 
consider waiting for specification clarity before jumping over it

>
> On Wed, Aug 20, 2025 at 6:52 PM Dan Smith <daniel.smith at oracle.com> wrote:
>
>     For some context, there's a longstanding known issue that the
>     interaction between intersections and wildcards is
>     under-specified. Deciding which intersections are well-formed, and
>     if so what are the types of their members, is a deep problem
>     without easy answers.
>
>     JDK-7034922 captures some of the issues, and I see this bug has
>     been linked to it.
>
>     So yes, this is intuitively a bug, but the problem is we don't
>     have a specification to conform to, and it's not clear what that
>     specification should say.
>
>     I've done some work in the past to try to make sense of the
>     intended type system, but that work hasn't gotten to the point of
>     actionable changes. In the mean time I think this is just one more
>     test case for these features that we can keep track of.
>

Vicente
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250820/ba0bd981/attachment-0001.htm>