Interesting.
public List<? extends T> SearchAction.search()
being declared in a non generic type or generic type that did not define T
should be a compile time error. You are getting away with it because the
type variable happens to be called T in SearchAction (I imagine) - and we
aren't checking. If this declaration is changed to:
public List<? extends X> SearchAction.search()
it will complain that X cannot be found.
However, I still believe:
List<? extends X> SearchAction<X>.search()
leads to an 'inconsistent class file' as the signature attribute will name
missing type variables.
cheers,
Andy.
2008/10/28 Dave Whittaker <[EMAIL PROTECTED]>
> Ok, I tried to set up a small test project so that I could try out your
> type stripper, and of course I couldn't replicate the problem. So I brought
> in more and more of the classes and aspects from the main project until I
> noticed something odd. In the test project SearchActionAspect where the
> search() ITD is defined caused no errors in the original project, but in the
> test project it showed up as a type mismatch. When I looked a bit closer I
> realized that the ITD was defined as
> public List<? extends T> SearchAction.search()
>
> rather than,
>
> public List<? extends T> SearchAction<T>.search()
>
> And adding the type variable within the original project has stopped the
> NPE from happening. So I think there is still a bug here, whether it's due
> to no error marker showing up in the original project, or to the different
> way the method is mixed in if the type variable is not added to the marker
> interface, but I'm stumped again as to what really happened.
>
> Dave Whittaker
> Iradix, LLC
> (p) 212.513.0874 x100
> (f) 212.504.8213
> [EMAIL PROTECTED]
>
> On Oct 28, 2008, at 3:15 PM, Andy Clement wrote:
>
> Ok - I will do a build that has a flag to turn off the capturing of that
> information in the signature attribute for the itd declaration in the
> aspect. It should only be used for the final build of your code that you
> are going to deploy - as incremental compilation will break horribly (I
> imagine) if an incremental build is attempted whilst this attribute is
> missing from the ITD. (that is where the big bunch of work will be, sorting
> that out properly). But at least this will tell us if the strategy will
> work before investing a lot of time to go down this road.
> cheers,
> Andy.
>
> 2008/10/28 Dave Whittaker <[EMAIL PROTECTED]>
>
>> Ok, I think I have a much better feel for what's happening here now. I
>> think that this particular error is triggered by the interface:
>> public class SearchAction<T>{
>>
>> public List<? extends T> search(){
>> ...
>> }
>>
>> ....
>>
>> }
>>
>> From the debugging that I did, that search method was where it was blowing
>> up. I'm not entirely sure of the whole sequence of events, but I guess if
>> it is the search() method on the aspect itself that hibernate validator is
>> trying to resolve it would expect to find T referenced by the aspect class
>> and quite possibly fail with an NPE when it's not there. I'm not that
>> familiar with how AspectJ does it's delegation of method calls to the
>> aspects providing their implementation, but if the aspect instance is
>> contained in a field within the advised class, it would probably be checked,
>> and I think this would all make sense.
>>
>> So if I'm following you, I would think that stripping the generic
>> signatures from the methods within the aspect class should be fine. The
>> interfaces generic signature will still be available, which is what calls
>> are made to from user code, and I don't think having that typing
>> information available from the aspect at runtime would be too important...
>> not to me anyway...
>>
>>
>> On Oct 28, 2008, at 2:11 PM, Andy Clement wrote:
>>
>> If it is taking the class file apart to analyse the type parameters, it
>> might well be tripping over the inconsistency in the signature attribute.
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=244619
>>
>> I think the solution is not to use the Signature attribute in this case to
>> capture something that will trip up other tools - however that will mean the
>> other tools will not know it is a generic declaration and who knows if they
>> can cope with that. It all comes down to this kind of problem:
>>
>> interface I<T> {}
>>
>> aspect X {
>> public void I<Z>.foo(Z z) {}
>> }
>>
>> The type parameter Z for the intertype declaration isn't anywhere to be
>> found in type X. It is not a generic method and it is not a generic aspect
>> and so resolving Z without being aware that it is a generic intertype
>> declaration is tough (only AspectJ knows that it is a reference to the type
>> variable in type I). If the fact that the method is parameterized is
>> captured in a normal Java signature attribute against method foo() in the
>> aspect then any tool (java compiler or something else) will look at that
>> attribute and go 'I dont know what Z you are talking about' which manifests
>> as an 'inconsistent class file' in the JDT compiler and possibly your NPE in
>> seam. So to answer your questions:
>>
>> > my question is... is that the same issue I'm seeing here as well? Is
>> AspectJ writing a Type value that is unresolvable at runtime via
>> reflection?
>>
>> could well be. I don't know what the other tool wants to do with the type
>> parameter. The full solution is a bunch of work - but a first pass could be
>> to remove the signature attribute from these methods and see if the tool is
>> happy. It will not know that the ITD is generic but it may not really care.
>> Do you want to try this out? Do you know precisely which method it is
>> tripping up over - is it the manifestation of the ITD in the target types
>> (the mangled ajc$inter* methods) or is it the declaration of the ITD in the
>> aspect type?
>>
>> cheers,
>> Andy.
>>
>> 2008/10/28 Dave Whittaker <[EMAIL PROTECTED]>
>>
>>> I'm seeing some new weirdness with ITDs that mixin generic methods and I
>>> wanted to see if anybody could give me a clearer understanding of what's
>>> going on. The issue is: I have a bunch of marker interfaces which I use to
>>> piece together the actions available on an object in a webapp (Create,
>>> Update, Delete, etc). Thanks to Andy's recent bug fixes, this is working
>>> pretty well and using JSF components that recognize these marker interfaces
>>> and generate a lot of the HTML / Action Invocations for me it might make my
>>> life a lot easier. The problem is I'm also using the JBoss Seam framework
>>> which has some strong ties to the Hibernate Validator framework. To make a
>>> long story short, when certain methods are invoked on my actions, Seam
>>> insists on using the Hibernate Validator to validate the entire class, the
>>> Hibernate Validator tries to do a runtime resolution of type parameters, and
>>> the whole thing dies with an NPE. Now, I know that there are still issue
>>> with how types are written out in woven class files which has caused the
>>> inconsistent class file error up until recently, so my question is... is
>>> that the same issue I'm seeing here as well? Is AspectJ writing a Type
>>> value that is unresolvable at runtime via reflection? Or am I looking in
>>> the wrong place?
>>>
>>> Thanks.
>>> _______________________________________________
>>> aspectj-users mailing list
>>> [email protected]
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>>
>>
>> _______________________________________________
>> aspectj-users mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>>
>> _______________________________________________
>> aspectj-users mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
>
> _______________________________________________
> aspectj-users mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
