-
Bug
-
Resolution: Fixed
-
P3
-
None
-
Verified
Consider two upper bounds, at least one of which mentions an inference variable:
a <: Foo<b>
a <: Bar<String>
If these upper bounds share a parameterized type, we can infer additional constraints from the type arguments (e.g., maybe b = String).
Here's an example (notably, this compiles in 7, due to a quirk in javac's implementation):
interface Task<E extends Exception> {}
class Comparator<T> {}
class CustomException extends Exception {}
class TaskQueue<E extends Exception, T extends Task<E>> {}
abstract class Test {
abstract <E extends Exception, T extends Task<E>>
TaskQueue<E, T> create(Comparator<? super T> comparator);
void f(Comparator<Task<CustomException>> comp) {
TaskQueue<CustomException, Task<CustomException>> queue = create(comp);
}
}
Reported on lambda-dev: http://mail.openjdk.java.net/pipermail/lambda-dev/2013-November/011442.html
a <: Foo<b>
a <: Bar<String>
If these upper bounds share a parameterized type, we can infer additional constraints from the type arguments (e.g., maybe b = String).
Here's an example (notably, this compiles in 7, due to a quirk in javac's implementation):
interface Task<E extends Exception> {}
class Comparator<T> {}
class CustomException extends Exception {}
class TaskQueue<E extends Exception, T extends Task<E>> {}
abstract class Test {
abstract <E extends Exception, T extends Task<E>>
TaskQueue<E, T> create(Comparator<? super T> comparator);
void f(Comparator<Task<CustomException>> comp) {
TaskQueue<CustomException, Task<CustomException>> queue = create(comp);
}
}
Reported on lambda-dev: http://mail.openjdk.java.net/pipermail/lambda-dev/2013-November/011442.html
- relates to
-
JDK-8037474 Failure to detect conflicting upper bounds in inference
- Closed
-
JDK-8029002 javac should take multiple upper bounds into account in incorporation
- Resolved