yangxu998 / guava-libraries

Automatically exported from code.google.com/p/guava-libraries
Apache License 2.0
0 stars 0 forks source link

Using Maps.newTreeMap(Comparator) triggers openJDK bug. #635

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create TreeMapExample.java as follows:

import java.util.Comparator;
import java.util.TreeMap;
import com.google.common.collect.Maps;

public class TreeMapExample {
  public static final Comparator<String> foo = null;
  private TreeMap<String, String> instance = Maps.newTreeMap(foo);
}

2. Compile this using OpenJDK 1.6.0_20

What is the expected output? What do you see instead?

This should compile without errors; instead, the compiler outputs:
TreeMapExample.java:7: incompatible types; no instance(s) of type variable(s) 
K,V exist so that java.util.TreeMap<K,V> conforms to 
java.util.TreeMap<java.lang.String,java.lang.String>
found   : <K,V>java.util.TreeMap<K,V>
required: java.util.TreeMap<java.lang.String,java.lang.String>
  private TreeMap<String, String> instance = Maps.newTreeMap(foo);

What version of the product are you using? On what operating system?
guava r08 on Linux.

Please provide any additional information below.

I believe this is tied to openjdk bug 100167 
(https://bugs.openjdk.java.net/show_bug.cgi?id=100167).

The current version of newTreeMap has the following signature and comment:

  public static <C, K extends C, V> TreeMap<K, V> newTreeMap(
      @Nullable Comparator<C> comparator) {
    // Ideally, the extra type parameter "C" shouldn't be necessary. It is a
    // work-around of a compiler type inference quirk that prevents the
    // following code from being compiled:
    // Comparator<Class<?>> comparator = null;
    // Map<Class<? extends Throwable>, String> map = newTreeMap(comparator);
    return new TreeMap<K, V>(comparator);
  }

Interestingly, changing the signature to its old (pre v40 in 
google-collections) signature:

  public static <K, V> TreeMap<K, V> newTreeMap(Comparator<? super K> comparator)

fixes the problem. I'm not sure what combination of javac and client code was 
causing issues with the original signature, but I cannot reproduce it at this 
point with any versions (Oracle or openjdk) of javac that I've tried.

Original issue reported on code.google.com by ian.b.ro...@gmail.com on 29 May 2011 at 8:05

GoogleCodeExporter commented 9 years ago
We'll look into it.

Original comment by kevinb@google.com on 13 Jul 2011 at 6:55

GoogleCodeExporter commented 9 years ago
Ok, we looked into it.  But, I'm not sure what we can do about it.  As you 
note, we're caught between a rock and a hard place here.  We probably can't 
make any change without negatively affecting some users in some way, so it's 
only worth doing if we know the change is to the definite best correct shining 
perfect signature.

Original comment by kevinb@google.com on 4 Aug 2011 at 8:36

GoogleCodeExporter commented 9 years ago
This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

GoogleCodeExporter commented 9 years ago

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09