-
Bug
-
Resolution: Unresolved
-
P4
-
5.0, 7, 8
This does not consider the possibility that one of Ck or Ti' may be a wildcard-paramterized type.
<T extends Iterable<?>> void m1() {}
<T extends Iterable<?> & Comparable<?>> void m2() {}
In this case, the members of the supertypes (and, therefore, the members of the intersection) are undefined (4.5.2).
It seems like the right thing to do is to make Ti' = capture(Ti), and similar for Ck. But some caution is warranted, since capture variables do not otherwise appear in class declarations.
It would also be possible to express the implicit class generically:
Given type C<?> & D<? extends Foo, ? super Bar>
We have class:
class Intersect<S extends Bounds1, T extends Bounds2, U extends Bounds3> implements C<S>, D<T, U> {}
And the members of the intersection are the members of class Intersect<?, ? extends Foo, ? super Bar>
That's a lot of work to specify, though . . . If nothing else, the fact that it could be done demonstrates that the capture alternative, which works out to the same thing, is fundamentally sound.
- blocks
-
JDK-8012039 enum type variable not within its bound
- Open
-
JDK-8027386 Compiler regression error on multi-level abstract generic class with intersection types
- Open
-
JDK-8081318 Diamond inference fails to infer capture variable parameterization
- Open
- duplicates
-
JDK-8046690 4.9: Intersection type with unbounded wildcard legal?
- Closed
- relates to
-
JDK-7040590 Intersection types: membership of intersection types in unspecified in some cases
- Open
-
JDK-8043374 GLB ignores different parameterizations of the same type
- Open
-
JDK-6391995 REGRESSION: removal of "rvalue conversion" causes problems
- Closed
-
JDK-7034495 Javac asserts on usage of wildcards in bounds
- Closed
-
JDK-8057800 Method reference with generic type creates NPE when compiling
- Closed
-
JDK-8015101 Covariance of return type implied by upper bounding on type parameter is ignored
- Closed