"Chained" qualified instance creation expressions (diamond in qualifiers)
Srikanth
srikanth.adayapalam at oracle.com
Thu May 7 12:51:04 UTC 2015
On Thursday 07 May 2015 06:10 PM, Srikanth wrote:
> I'll wait for Dan to chime in with chapter and verse, but I believe
> the specification does not
> mandate/require/sanction/allow a qualified instance creation
> expression to propagate
> the target type or any part thereof to any enclosing instance creation
> expression (qualified
> or otherwise).
Sorry, upon rereading your mail, I see that this is something you are
acknowledging and
your question is broader. I'll study this in more detail tomorrow.
Srikanth
>
> Srikanth
>
>
> On Wednesday 06 May 2015 07:36 PM, Georgiy Rakov wrote:
>> Hello,
>>
>> let's consider following example:
>>
>> classD {}
>>
>> classOuter2<Q> {
>> classOuter1<W> {
>> classFoo<T> { }
>> }
>> }
>>
>> public classTest69 {
>>
>> public static voidtest(String argv[]) {
>> Outer2<?superD>.Outer1<?superD>.Foo<?superD> f20 =newOuter2<>().newOuter1<>().newFoo<>() {
>> privateOuter2<Object>.Outer1<Object>.Foo<D> simpleMethod1() {return this; }//compiles Ok
>> //private Outer2<D>.Outer1<D>.Foo<D> simpleMethod2() { return this; } //causes compilation error
>> };
>> }
>> }
>>
>>
>> JDK9b60 causes Q and W to be inferred as Object. This can be seen:
>> - from the fact that code above compiles successfully;
>> - from the fact that uncommenting the method above causes compilation
>> failure.
>>
>> So what we actually have is:
>> - Q is inferred as Object;
>> - W is inferred as Object;
>> - T is inferred as D.
>>
>> However according to intuition it seems that Q and W should have been
>> inferred as D as it happens to T.
>>
>> I believe this corresponds to spec, the reasons presented below seem
>> to cause this:
>>
>> 1. Following assertion from JLS 18.5.2 is not applied when JLS 15.9.3
>> is applied to new Outer2<>() and new Outer1<>():
>>
>> Otherwise, the constraint formula ‹Rθ→T› is reduced and
>> incorporated with B_2 .
>>
>> So for outer classes inference proceeds with no constraint formula
>> actually causing inference variable in question to be inferred as D.
>>
>> 2. JLS 15.9.3 doesn't use type parameters from outer classes when
>> processing new Foo<>(). Namely following assertion from JLS 15.9.3
>> doesn't mention type parameters from possible outer classes:
>>
>> Let F_1 ...F_p be the type parameters of C, and let G_1 ...G_q be
>> the type parameters (if any) of |c_j |.
>>
>> So constraint formula created by JLS 18.5.2 assertion presented above
>> engages just inference variable from Foo, i. e. T.
>>
>> However I believe more broad change of spec will be required to
>> implement this "intuition" than just modifying spec according to two
>> points above.
>>
>> So:
>> 1. Could you please tell if I understand correctly that the fact that
>> Q is inferred as Object, W is inferred as Object really corresponds
>> to spec and it's not a JDK issue.
>> 2. As for me it looks reasonable to enhance specification so that Q
>> and W would be inferred as D too. Could you please tell if you agree.
>> If you do would it be worth creating spec enhancement in Jira?
>>
>> Thanks,
>> Georgiy.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150507/4de47356/attachment-0001.html>
More information about the compiler-dev
mailing list