Bug 544646

Description Alexander Kriegisch 2019-02-20 19:48:36 EST

Created attachment 277636 [details]
Demo project using runtime type matching as a workaround

Quoting myself from the mailing list because Andy asked me to create a ticket:

In my answer [1] to a StackOverflow question I tried to explain to the original poster why he cannot use a concrete type in order to limit method parameter matching for a method defined in a generic supertype. I also showed him a workaround using the concrete type in 'args()' because then he can utilise runtime information. I also pointed him to the AJ generics manual [2]. I am not a generics expert, but I do see with javap that, as I expected, the method in question actually has an Object parameter in the byte code. Anyway, the OP has a point there, saying that his derived type specifies the concrete type for the generic supertype, but of course he does not override the method from the generic superclass.

If you compile my attached sample code (it is an Eclipse project) you see that my workaround pointcut works, but if you use javap on both abstract supertypes AbstractIntegerConverter and AbstractStringConverter you also see that aspect code for the around advice is generated for both of them because there is no way I know of to limit the pointcut any further.

My question is: Do you think it would be possible to utilise the type information present in the subclasses IntegerToStringConverter and StringToIntegerConverter (javap shows there is information present) in order to limit bytecode weaving to what is actually the pointcut's target, i.e. extending generics functionality in AspectJ to utilise existing type information in order to enable more specific pointcuts and eliminate the need to use runtime types via args(), target() or this()?

[1] https://stackoverflow.com/a/54730041/1082681
[2] https://www.eclipse.org/aspectj/doc/next/adk15notebook/generics-inAspectJ5.html