The Model and JUnit

my understanding is that
T in AbstractGenerics is not resolved in your system.
Because T is a subtype of AbstractGenerics<U>, U not being resolved.
Am I wrong?

WDYT?

T in AbstractGenerics is not resolved - this is correct.
But T has an upper bound: it must be a subclass of AbstractGenerics.
As I mentioned before, I'm not sure if this is sufficient data to build up the model, but I hope it could be arranged to be enough.
So it may not be a bug but a feature request...

In general, upper bounds should be recognized (except for some special cases, such as multiple upper bounds, where we just give up and approximate the type to Object). I'll look into this.

this case is an infinite multiple upper bound case, if you compute at the infinite limit you should find the type

It's a broader problem than I thought. I'm still not 100% sure that fixing it will change the behaviour described by Sebastian, but I found other cases that are more clearly pathological. For example, this is not approximated correctly, even if in theory it should:

class SomeGenericType<T extends SomeType> {
public T property() {return null;}
}

We don't even have recursive definitions here, but HA still doesn't notice that the property type can be approximated to a SomeType. The problem is that I focused on resolving generic types in hierarchies - but there are cases (like the one above) where you can make a decent approximation of types by just looking at the class itself. It's not really a bug, as this is on the border of what people should be expecting to do - but as a feature request, it's very reasonable. What do you think, Emmanuel?

We have many corner cases where type binding doesn't work as well as Java's - generics in interfaces, inner classes and so on. Java makes extremely difficult to work reflexively at this level. This one probably deserves fixing, though.

After some thought, this is a slippery slope. If we accept this:

class SomeGenericType<T extends SomeType> {
public T property() {return null;}
}

Then there is no reason why we shouldn't accept this implicit upper bound as well:

class SomeOtherGenericType<T> {
public T property() {return null;} // T is approximated to Object
}

The problem is how much we want to push this type of guessing. I see four options:

1 - The system tries to be smart and approximates all generic types as well as it can. List<T extends Runnable> becomes List<Runnable>, T becomes Object and so on. This might cause problems at runtime, of course.
2 - The system does as above, but logs a warning every time an approximated type is registered.
3 - The system approximates only in certain situations. Maybe different approximation strategies can be plugged in.
4 - The system doesn't try to be too smart, and throws an error whenever a type is not fully resolved.

Emmanuel, WDYT?

1 - The system tries to be smart and approximates all generic types as well as it can. List<T extends Runnable> becomes List<Runnable>, T becomes Object and so on. This might cause problems at runtime, of course.

> I'm OK for everything but Object, if you declare an upper bound, you tend to know what you are doing. However, for Object people would be too surprised, esp the one not understqnding generics ( like me )

2 - The system does as above, but logs a warning every time an approximated type is registered.

-1, we had that but the user experience was bad for Hibernate Validator

3 - The system approximates only in certain situations. Maybe different approximation strategies can be plugged in.

An approximation strategy might be interesting, we sort of have that through the boolean rendering true/false depending on whether approximation was used or not

4 - The system doesn't try to be too smart, and throws an error whenever a type is not fully resolved.

-1 there are usecases that require approximation

Hi Paolo!

I stumbled upon another issue - see second zip file.

I'm not sure if it has the same cause like the other stuff, but it is at least related. Please check the provided TestCase...

To Sebastian: whoops, I think you posted the .class files instead of the source.

Should have made me wonder when I had to rename the .jar to .zip...