Re: [Jastadd] Question on types such as "wildcards.& java.lang.Integer& java.lang.String"

From: Jesper Öqvist <jesper.oqvist_at_cs.lth.se>
Date: Mon, 21 Jan 2013 19:20:57 +0100

Well it is already implemented, just not working correctly, so the best
thing to do would be to fix the current implementation.

/Jesper

On 2013-01-21 17:13, Eric Bodden wrote:
> Hi Jesper.
>
> Thanks a lot for digging this out. Indeed this sounds like a "nice"
> little project in its own... I wonder whether instead it would make
> sense to instead implement something simpler that would be incomplete
> but still work for common cases. For instance, our example makes no
> use of generics, so one could, for instance, first implement a version
> that ignores the issue of generics.
>
> (on the other hand it may also be just as easy or hard to implement it
> right - it's hard for me to tell)
>
> Eric
>
> On 21 January 2013 16:34, Jesper Öqvist <jesper.oqvist_at_cs.lth.se> wrote:
>> My original answer to why it is so complicated was incorrect. It was a while
>> since I looked at this last time, so I forgot some of the details, I've been
>> reading the specification now
>> (http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.2.7)
>> and here is my revised answer to why the LUBType computation is complicated:
>>
>> The lub type is used in method type inference when there are some type
>> bounds U_1 ... U_k inferred from the context. We need to find a type T_j
>> that fits these bounds. First we construct the sets of all supertypes of all
>> type bounds ST(U_i) and in order to intersect these sets we need to take the
>> erased versions of the types in the supertype sets. Now we can get a type
>> that fits the bounds, but it is erased. Finding the type arguments (if the
>> result type was generic) is the hairy part where things become very fiddly.
>>
>> TL;DR; generics complicate things.
>>
>> /Jesper
>>
>>
>>
>> On 01/18/2013 04:20 PM, Eric Bodden wrote:
>>>> The type of an expression such as the one in your example is incorrectly
>>>> evaluated in JastAddJ currently.
>>>> This has been known for some time know. I added the bug on the issue
>>>> tracker
>>>> when I was working on Java 7.
>>>>
>>>> It's not something that we can easily fix, if you have any suggestions I
>>>> would be all ears! The type analysis concerning LUBType is *very*
>>>> complicated. I was planning to work through it at some point and try to
>>>> get
>>>> an understanding of why it currently doesn't work but right now I have no
>>>> clue.
>>> Thanks for conforming. I wonder: why is this so hard? At least for
>>> reference types, don't you "just" have to search for the common first
>>> ancestor in the class hierarchy?
>>>
>>> Cheers,
>>> Eric
>>
>> _______________________________________________
>> JastAdd mailing list
>> JastAdd_at_cs.lth.se
>> https://mail1.cs.lth.se/cgi-bin/mailman/listinfo/jastadd
>
>
Received on Mon Jan 21 2013 - 19:20:58 CET

This archive was generated by hypermail 2.3.0 : Wed Apr 16 2014 - 17:19:06 CEST