I have a non-trivial source tree that crashes javac with the following stack trace:

The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
        at com.sun.tools.javac.code.Type$WildcardType.accept(Type.java:415)
        at com.sun.tools.javac.code.Types$MapVisitor.visit(Types.java:3214)
        at com.sun.tools.javac.code.Types.upperBound(Types.java:95)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2968)
        at com.sun.tools.javac.code.Types.adapt(Types.java:2998)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2959)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2968)
        at com.sun.tools.javac.code.Types.adapt(Types.java:2998)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2959)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2968)
        at com.sun.tools.javac.code.Types.adapt(Types.java:2998)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2959)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2968)
        at com.sun.tools.javac.code.Types.adapt(Types.java:2998)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2959)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2968)
        at com.sun.tools.javac.code.Types.adapt(Types.java:2998)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2959)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2968)
        at com.sun.tools.javac.code.Types.adapt(Types.java:2998)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2959)
        at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2968)

This happens with the following java versoin on Linux:

  : java -fullversion
  java full version "1.6.0_01-b06"

If this can be fixed w/o a test case, that would be wonderful, but otherwise to produce a test case I need to identify which part of the source file is causing this problem. Is there anyway to run javac with some sort of debug flag so that I can figure out which source file is failing to compile? I think that is necessary for me to come up with a smaller test case.
Posted Date : 2007-07-27 01:49:46.0

Here's a very small test case:

class A<T extends A<?>> {}
class B extends A<A<?>> {}

class Test {
    A<A<?>> t = null;
    B c = (B)t;
}
Posted Date : 2008-10-09 11:26:17.0

N/A

To figure out the file in question, it should be enough to use -verbose.
Posted Date : 2007-07-27 02:13:57.0

The problem is in Types.adapt - the goal of this method is to adapt two generic instantiation by 'unifying' their type-variables (if they contain some). E.g.
adapt(List<T>, List<String>, emptylist, emptylist)
will add the mapping T->String (that is, T is added in the first list, while String is added in the second list).

This method is quite complex as,  because of wildcards and type-variables, the method should adapt upper/lower bounds of a given type recursively. As a result it might happen that (because of fbounds) adapting two generic types A and B ends up in an endless loop.

In this case we have that A<A<?>> and A<A<?>> should adapted (the two types are the same - but we should adapt them nevertheless).

1. adapt(A<A<?>>, A<A<?>>)
2. adapt(A<?>, A<?>)
3. adapt(?, ?) 
3b. adapt(ub(?), ub(?))
3c. adapt(ub(T), ub(T))
4. adapt(A<?>, A<?>)
...
...

The solution is to adopt a solution similar to the one xploited by the fix of CR 6207386 - that is, adapt should use an internal cache where to store all the pairs of 'already adapted' types; if a type is encountered twice during the same call to adapt(), adapt should give up as no improvement over the current mapping can be achieved.
Posted Date : 2008-10-09 13:37:56.0