Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 521814

Summary: [compiler] bounds check succeeds in the presence of wildcards but fails in their absence
Product: [Eclipse Project] JDT Reporter: Sasikanth Bharadwaj <sasikanth.bharadwaj>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: jarthana, stephan.herrmann
Version: 4.8   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Sasikanth Bharadwaj CLA 2017-09-04 06:26:08 EDT
Consider this example

public class X  {
    public static void main(String argv[]) {
    	f(new ArrayList<List<? extends String>>()); // remove wildcard to get error
    }
    static <Q extends List<Integer>> String f(List<? super Q> c) {
    	return null;
    }
} 
This code compiles fine in eclipse but javac complains about the method not being applicable because of bounds mismatch.
Note that eclipse too gives the same error if we remove the wild card from either the invocation or the declaration of the method f.
Although I'm not 100% certain which behavior is right, the fact that removing the wildcard changes eclipse's behavior makes me think we may have a bug
Comment 1 Eclipse Genie CLA 2020-03-29 11:34:52 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. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. 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.
Comment 2 Jay Arthanareeswaran CLA 2023-03-07 11:40:53 EST
I just happened to check this with latest ECJ and Javac and now we both reject this code.

Stephan, any idea what happened here? If not, it will help if you can run your magic tool to find out since when this change came about.
Comment 3 Stephan Herrmann CLA 2023-03-07 13:29:57 EST
The change happened between these versions:

accept:
Eclipse Compiler for Java(TM) v20190710-0739, 3.19.0, Copyright IBM Corp 2000, 2015. All rights reserved.

reject:
Eclipse Compiler for Java(TM) v20190903-0936, 3.19.0, Copyright IBM Corp 2000, 2015. All rights reserved.

From a quick scan I couldn't find a bug from that interval that sounds very much related?

Do you want me to do a commit level bisect, to find the exact change?