arrays and raw types in 18.2.3
Stephan Herrmann
stephan.herrmann at berlin.de
Thu Oct 10 05:01:32 PDT 2013
On 10/09/2013 12:23 AM, Dan Smith wrote:
> On Oct 8, 2013, at 2:06 PM, Stephan Herrmann wrote:
>> 18.2.3
>> o If T is an array type, T'[], then let S'[] be the most specific array type that is a supertype of S (or S itself)
>>
>> ...
>
> This is to account for type variables and intersection types. I know there are some restrictions on what bounded type variables can look like in source (including their intersection upper bounds), but through things like capture or lub I'm pretty sure you can end up with cases in which both of these kinds of types can be subtypes of array types.
Thanks, makes sense.
>> Secondly, how should this constraint be reduced:
>> C <: C<α>
>> According to 18.2.3 I need a parameterization of C
>> that is a supertype of C (raw).
>> Since no such supertype exists,
>> some invocations of generic methods with raw arguments
>> seem to be illegal now, which were legal in Java 7.
>
> Before you get to subtyping, you'll usually have a compatibility constraint of the form "C -> C<α>"; see 18.2.2.
>
> The note #1 points out that the text still needs to account for unchecked exceptions. Actual spec text to come in the next round. These compatibility constraints should work as before: if the statement can be made true via unchecked conversion, then the result is "true". (And there will be an unchecked warning based on the requirement somewhere in 15.12.2.)
I read that IFF the constraint comes via a compatibility constraint a future version
of the spec will tell me how to leverage unchecked conversions (not exceptions :)).
I'm eagerly looking forward to that update :)
>> I'm currently looking at this test:
>>
>> public class X {
>> public static void main(String[] args) {
>> EntityKey entityKey = null;
>> new EntityCondenser().condense(entityKey);
>> }
>> public static class EntityCondenser {
>> <I, E extends EntityType<I, E, K>, K extends EntityKey<I>> void condense(K entityKey) {
>> }
>> }
>> public class EntityKey<I> {}
>> public interface EntityType<
>> I,
>> E extends EntityType<I, E, K>,
>> K extends EntityKey<I>> {
>> }
>> }
>
> Ah, okay, in this case, there is no compatibility constraint for the two types ("Raw -> Parameterized"), just a subtyping constraint ("Raw <: Parameterized"), which is derived from the bound of K.
>
> The old spec was somewhat vague here, but I believe the correct behavior for both 7 and 8 is to fail.
If that is so, then all(?) existing compilers have a bug: they do accept this program.
I just checked, even javac8 b109 accepts the above test.
Will this be changed in the near future?
best,
Stephan
More information about the lambda-spec-experts
mailing list