Very true. That's what i told them at IBM HRL (Score 4, Interesting)

When i worked at IBM research labs, i criticized AspectJ using almost exactly the same words: they try to solve specific issues (logging, persistency, etc), that deserve specific solutions, using a completely generic approach. They failed to provide more examples for those specific problems that AspectJ will solve. Of course, i was silenced - because that's the way it works in IBM Haifa - they just can't deal with criticism :)

The concepts behind AspectJ, TMO, are not bright. They break encapsulation, they are too ambitious and far from real-world understanding of programming concerns. All in all, they introduce too many problems.

TMHO,Aspect Oriented Programming should be different, and should be based on something much simpler, much more down-to-earth ideas and more consistent with real-world needs.

Today it is easily possible to do using Java Annotations, that will specify class member's affinity with an aspect, and thus provide:

A) a mechanism by which the compiler could limit access (errors & warnings) to members according to their affinity with a common aspect or aspects (common to it and its caller);

B) a programmer, using a proper IDE, can view a breakdown of his code according to aspects.

C) in runtime, the current aspect should be visible to the program thus extending the ability to: I) log, and trace errors; II) affect work-flow according to the aspect in action (that's an intense feature so im not too sure about that)

Doing more than the above, looks to be like an abuse of proper programming concepts.

The Annotation mechanism introduced in Java 5 is quite powerful and maybe already provide all that is needed for the job, including hierarchical arrangement of aspects (slash annotations), attributes, etc. Very little is needed in order to implement what i propose.

Maybe i'll propose is to the JCP. What'd ya think?