I like to add Spring's JMX annotations to my services using ITDs so I can look at the internals with the JConsole. I currently do this from an aspect with:
declare @type : MyServiceImpl : @ManagedResource( ...) declare @method : public void MyServiceImpl.myMethod() : @ManagedOperation( ... ) I don't think it is hard to understand, but the proposal would indeed make it a bit shorter. However, using 'on' as a keyword seems a bit short and might be easily missed or read over I think. regards, Wim 2009/6/17 Andy Clement <[email protected]> > Worth quoting the related enhancement request I think - Dave's musings > on thread http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg10106.html > gave rise to https://bugs.eclipse.org/bugs/show_bug.cgi?id=261728 > > Out of interest, why did you feel the need to use 'on' rather than > intertype? Just because it is a shorter option? Did it mean something > different to you than 'intertype'? Do you think intertype scares > users? 'on' to me perhaps suggests activities executing based on some > event occurring, rather than what we are trying to do here. > > >From that bug report: > > public aspect ITDAspect{ > intertype ITDInterface{ > public String value; > public String getValue(){ > return value; > } > public void setValue(String value){ > this.value = value; > } > } > } > > > If I dig through that old thread, there are some issues that I should > have added to the bug report but haven't yet. Things like: > - does this new syntax provide a way to ITD a static initializer? > - does this new syntax provide a way to ITD an inner class? > > Changes to the ITD syntax would clearly benefit something like Spring > Roo which makes heavy heavy use of ITDs. It uses so many that I think > we could probably noticeably improve the compile times for Roo > projects by changing syntax. > > But something that thread had not touched upon, nor does the current > enhancement request - but you have touched upon today - is the > annotation of existing members: > > // Existing field > @FieldLevelAnnotation > on String name; > > // Existing method > @MethodLevelAnnotation > on void doThat(); > > // Existing constructor > @ConstructorAnnotation > on MyOndBean(int); > > I feel like there might be another even neater way to express this, > but I can't quite put my finger on what it is. If the current is: > > declare @field: String name: @FieldLevelAnnotation; > > Above we have: > > @FieldLevelAnnotation on String name; > > mmmm, > > @+FieldLevelAnnotation String name; > > Not sure. > > > As you can see, this could be implemented as plain syntactical sugar, it > could even be possible to > > write a set of regular expressions or a simple parser to convert from > this new syntax to the current one. > > syntax sugar is definetly the way to go initially - but it is not at > all trivial due to the grammar changes (if making it a real language > feature of AspectJ instead of transforming new syntax to existing). I > can already picture some enhancements to the weaving code in the face > of large scale ITD usage if we can move to something more like this > model. Perhaps regexs are the way to get some users refactoring their > code to try this style out and validate the constructs - before diving > into the heavy lifting of changing the grammar. But i'm not sure how > a regex approach would affect incremental compilation analysis. > > Andy. > > 2009/6/16 Simone Gianni <[email protected]> > > > > Hi all AspectJ users. > > > > There has been a discussion, about one year ago, about a simplified > syntax for ITDs. The discussion then diverged in another thread about > various ways of implementing ITD, which was not the original proposal made > by Dave Whittaker. > > > > During one more year of heavy ITD usage in my Apache "Magma" Lab, I had > time to think about it much deeper, and concluded that the original Dave's > idea is quite right, but could even be improved. > > > > So I'm writing to ask your ideas and comments on what follows. > > > > The problem is that the current syntax that AspectJ use to alter the Java > type system (ITDs, but also declare parents, declare @xxx etc..) is perfect > if you are modifying a large number of classes. For example, all classes > annotated with such and such will implement this interface. > > > > However, it is becoming more and more common the need to modify a single > class, adding a few methods, or adding annotations to it. In fact > annotations are becoming more and more important in Java programming, with > lots of framework depending on them, and lots of JSRs being published to > exploit annotations as much as possible. Having the ability to "add" > annotation on a class on a separate aspect, which could be applied or not, > is a very nice feature, but currently painful to obtain. > > > > Think for example of applying JSR-303 validation annotations or JPA ones > on existing code using current syntax. Since annotations will be different > for each field, it is quite a pain and quite unreadable. The power of > patterns is, in these case, useless and counterproductive. > > > > Dave's case of declaring fields and methods on the interface then used in > a declare parents, is a special and very common case of this situation. > > > > So, taking from Dave's proposal of introducing a new "intertype" keyword, > I'd like to put the bar a little higher and propose the introduction of the > "on" keyword. Please note that this syntax is not a complete alternative to > the existing one, but is a complementary syntax for the described use cases. > > > > A simple example will give a quick idea of how it could work : > > > > public class MyOldBean { > > private String name; > > private String surname; > > > > public MyOldBean(int i) { ... } > > > > public void doThat() { ... } > > } > > > > public aspect RevampMyOldBean { > > @ClassLevelAnnotation > > on MyOldBean implements NewInterface { > > // new field > > @FieldLevelAnnotation > > private String newField; > > > > // new constructor > > @ConstructorAnnotation > > public MyOldBean(String _newfield) { > > ... > > } > > // new method > > @MethodLevelAnnotation > > public String getNewField() { > > ... > > } > > > > // Existing field > > @FieldLevelAnnotation > > on String name; > > > > // Existing method > > @MethodLevelAnnotation > > on void doThat(); > > > > // Existing constructor > > @ConstructorAnnotation > > on MyOndBean(int); > > } > > > > // Dave's case > > on NewInterface { > > public void doThis() { ... } > > } > > > > } > > > > If you think of how this has to be written with current syntax, you'll > notice how less readable and more error prone it is. I'm not saying it will > be necessarily "longer" in the sense of typing, except for Dave's case where > there is an obvious reduction of typing, I'm thinking about readability and > complexity more than mere number of keystrokes, but I'm pretty sure also > number of keystrokes will be reduced. > > > > Moreover, refactoring methods from inside a class to an ITD aspect (or > the opposite) would be a matter of cut and paste. > > > > I'm not a guru when it comes to formal language definition, but I think > the "on" keyword could be defined like this : > > > > [<annotations>] > > on <Type> [extends <TypeList>][implements <TypeList>][ { <ITDBlock> } > > > > * Annotations declared before the "on" keyword have to be applied to > > the specified type and are interpreted as "declare @type" > > * The "extends" and "implements" clauses, if present, are to be > > applied to the specified type and are interpreted as "declare > parents" > > * The ITDBlock will contain new methods and/or the second form of > > the on keyword. > > > > > > The second form appear inside the ITDBlock of another "on" keyword. > > > > [<annotations>] > > on <MethodSig>|<FieldSig>|<ConstructorSig>; > > > > * Annotations declared before the "on" keyword have to be applied to > > the specified member and are interpreted as "declare @method" or > > "declare @field" or "declare @constructor" > > * Eventually, instead of signatures patterns could be used, given > > that a complete signature is a specialized form of pattern. > > > > > > As you can see, this could be implemented as plain syntactical sugar, it > could even be possible to write a set of regular expressions or a simple > parser to convert from this new syntax to the current one. > > > > I'd love to try to code this inside AspectJ, and make this my first real > code contribution to the project. > > > > WDYT? > > > > Simone > > > > -- > > Simone Gianni CEO Semeru s.r.l. Apache Committer > > http://www.simonegianni.it/ > > > > _______________________________________________ > > 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
