inferred type does not conform to upper bound(s)

Following code does not compile in javac (however, in compiles in Eclipse):

final Table<Integer, Integer, Integer> destination = HashBasedTable.create();
final Map<Integer, Integer> source = new HashMap<>();

// compiles
final Table<Integer, Integer, Integer> broker = source.entrySet().stream().collect( Tables.toTable( e -> 0, e -> 0, e -> 0, ( e1, e2 ) -> 0, HashBasedTable::create ) );
destination.putAll( broker );

// doesn't compile
destination.putAll( source.entrySet().stream().collect( Tables.toTable( e -> 0, e -> 0, e -> 0, ( e1, e2 ) -> 0, HashBasedTable::create ) ) );

I guess the problem could be with Guava, because when I do the same on simple maps like that, everything works fine:

Map<Integer, Integer> destination = new HashMap<>();
Map<Integer, Integer> source = new HashMap<>();

Map<Integer, Integer> broker = source.entrySet().stream().collect(Collectors.toMap(e -> 0, e -> 0));
destination.putAll(broker);

destination.putAll(source.entrySet().stream().collect(Collectors.toMap(e -> 0, e -> 0)));

I reported this to Oracle, and they want me to provide a case with native JDK, which I am not able to do, so if you’ll say it’s Java compiler fault, it would be really great if you could help me with such example.

[cpovirk]

You’re using the version of toTable that accepts a Supplier but not the version of toMap that accepts a Supplier. Here’s the equivalent JDK code, which fails to compile:

    destination.putAll(
        source.entrySet().stream()
            .collect(Collectors.toMap(e -> 0, e -> 0, (e1, e2) -> 0, HashMap::new)));

I do suspect that this is just a case in which type inference isn’t powerful enough for what we want, but if the outcome of the Oracle bug is “Oh, no, we should change the signature of Collectors.toMap,” then do let us know, as we should probably do the same for Tables.toTable.

[landawn]

@noelo-cohelo try the latest Java 8 version. maybe the issue is fixed