FULL PRODUCT VERSION :
java version "1.6.0_23"
Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Java HotSpot(TM) Client VM (build 19.0-b09, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The compiler is permitting the return value of a generic static method to be assigned to a parameterized variable of the wrong type.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile and run a class with the following code:
----------------------------------------------------------------------
  public static void main(String[] args) {
    Comparator<String> s = new Comparator<String>() {
      public int compare(String a, String b) {
        return a.compareToIgnoreCase(b);
      }
    };
    Comparator<Object> o = new Comparator<Object>() {
      public int compare(Object a, Object b) {
        return a.hashCode() - b.hashCode();
      }
    };
    Comparator<Boolean> c = GenericsBug.compose(s, o);
    c.compare(Boolean.TRUE, Boolean.FALSE);
  }
  
  public static <T> Comparator<T> compose(final Comparator<? super T> c0,
                                          final Comparator<? super T> c1) {
    return new Comparator<T>() {
      public int compare(T a, T b) {
        int comparison = c0.compare(a, b);
        return (comparison != 0) ? comparison : c1.compare(a, b);
      }
    };
  }
----------------------------------------------------------------------

In the absence of an explicit type argument when invoking the compose method, the compiler allows the result to be assigned to a parameterized variable of the wrong type.

Note that the compiler correctly disallows the assignment when the type argument is specified:
----------------------------------------------------------------------
    Comparator<Boolean> c = GenericsBug.<String>compose(s, o);
----------------------------------------------------------------------

As expected, the compiler correctly complains when the type argument is not a correct lower-bound.  Here the assignment itself is reasonable, but Boolean is not a lower-bound of String and Object:
----------------------------------------------------------------------
    Comparator<Boolean> c = GenericsBug.<Boolean>compose(s, o);
----------------------------------------------------------------------


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The compiler should not allow the following assignment:

Comparator<Boolean> c = GenericsBug.compose(s, o);

The compiler should produce an error, such as an "incompatible types" error:

found   : java.util.Comparator<java.lang.String>
required: java.util.Comparator<java.lang.Boolean>

ACTUAL -
No compile-time error -- instead there is a run-time error:

Exception in thread "main" java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String
        at GenericsBug$1.compare(GenericsBug.java:6)
        at GenericsBug$3.compare(GenericsBug.java:24)
        at GenericsBug.main(GenericsBug.java:17)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.Comparator;

public class GenericsBug {
  
  public static void main(String[] args) {
    Comparator<String> s = new Comparator<String>() {
      public int compare(String a, String b) {
        return a.compareToIgnoreCase(b);
      }
    };
    Comparator<Object> o = new Comparator<Object>() {
      public int compare(Object a, Object b) {
        return a.hashCode() - b.hashCode();
      }
    };
    Comparator<Boolean> c = GenericsBug.compose(s, o);
    c.compare(Boolean.TRUE, Boolean.FALSE);
  }
  
  public static <T> Comparator<T> compose(final Comparator<? super T> c0,
                                          final Comparator<? super T> c1) {
    return new Comparator<T>() {
      public int compare(T a, T b) {
        int comparison = c0.compare(a, b);
        return (comparison != 0) ? comparison : c1.compare(a, b);
      }
    };
  }
  
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Avoid use of type argument inference since relying on it, in this case at least, could allow the compiler to compile code that is not type-correct.