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
Received on Mon Jan 21 2013 - 16:34:16 CET