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

From: Jesper qvist <>
Date: Mon, 21 Jan 2013 16:34:32 +0100

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
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.


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

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