JDK-8043279 : WildcardType.bound unexpectedly changes values
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P5
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-05-15
  • Updated: 2015-12-11
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_majorUnresolved
Related Reports
Relates :  
Description
If I modify Check.firstIncompatibleTypeArg as follows, an AssertionError is triggered:

            while (args.nonEmpty() && tvars_cap.nonEmpty()) {
                // Let the actual arguments know their bound
                if (args.head instanceof WildcardType) {
                    Type oldBound = ((WildcardType) args.head).bound;
                    Type newBound = tvars_cap.head;
                    if (oldBound != newBound)
                        throw new AssertionError("wildcard bound mismatch in type " + type + ": "
                                            + oldBound + " of " + (oldBound == null ? "_" : oldBound.tsym.owner) + ", "
                                            + newBound + " of " + (newBound == null ? "_" : newBound.tsym.owner));
                }
                args = args.tail;
                tvars_cap = tvars_cap.tail;
            }

Example output (from an OpenJDK 'make'):
wildcard bound mismatch in type com.sun.tools.javac.util.ListBuffer<? super com.sun.tools.javac.tree.JCTree.JCVariableDecl>: E of java.util.Collection, A of com.sun.tools.javac.util.ListBuffer

I don't fully grasp the significance of the 'bound' field (or the implications of changing it), but clearly it is wrong to set it to different type parameters of different classes over the course of compilation.

I imagine the problem is due to a misuse of substitution.
Comments
This is the root cause of JDK-8043926. You can use the test case there to reproduce this issue.
08-07-2014