Support wildcards in target()

[ttho]

Hi, this is a question and a request for enhancement. Why can't I use wildcards in target() expressions like in

target(java.util.concurrent..*)?

This gives me the error message
wildcard type pattern not allowed, must use type name

Background:
I want to check if threads aren't concurrently accessing thread-unsafe collection classes, and exclude all classes in java.util.concurrent. For that, I track access to objects with an aspect and report an error if two threads access it at the same time. If I use the pointcut call(* java.util.concurrent..*(..)) instead, it does match on all methods defined in this package, but does not match the method calls coming through an interface outside of that package, like java.util.List.add() for example.
My workaround is to check the class name of the target object on every call interception, but I would like to have a more efficient way.

[kriegaex]

That would indeed be a new Feature. It might make pointcut matching for target, this, @target, @this slower and would cause complications when binding to advice parameters. If there is no explicit type, you would need to bind to Object and then inspect types via instanceof and cast in the advice code.

Due to "development team" capacity - currently just me in tiny time slices - I think this is not going to be implemented anytime soon. But often there are ways to achieve what developers want by other means. If you could provide an MCVE GitHub project and point to it in a Stack Overflow question, I might be able to help you with your workaround. Maybe what you so at present is already the best workaround imaginable, but I have no way of knowing for sure. Are you having performance problems due to your aspect? Did you measure that somehow?

[ttho]

Thanks for the quick reply. Your answer suggest me that what I am doing now - inspecting the type in the aspect code - is what AspectJ would have to do internally if it implemented this anyway. So the "more efficient way" comes down to solely a more efficient way to express this. Still it would be a nice feature.

[kriegaex]

Your answer suggest me that what I am doing now - inspecting the type in the aspect code - is what AspectJ would have to do internally if it implemented this anyway.

Yes, basically that is so. The pointcut types I listed above, among others, are always evaluated during runtime. The complexity would just be hidden inside AspectJ.

But like I said, maybe there is a way to do what you want more elegantly with on-board means. I have no way of knowing, only reading your textual description and not seeing the actual code.

[ttho]

But like I said, maybe there is a way to do what you want more elegantly with on-board means. I have no way of knowing, only reading your textual description and not seeing the actual code.

Yes, I understand, and your help would be much appreciated. However, the future of this feature I was working on is currently unclear for other reasons.