Aspects applications
Hi EAP-members!
A lot of votes have been given to the AspectJ support feature:
http://www.intellij.net/tracker/idea/viewSCR?publicId=2424
Could you share we us your thoughts about Aspect applications you may think
about?
Why would you like to use / not to use aspects in your code?
Any comments are welcome.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
请先登录再写评论。
Are you asking for examples that are more concrete than what's described at:
What are the benefits of using AspectJ?
http://aspectj.org/doc/dist/faq.html#q:benefits
Typical AspectJ programs
http://aspectj.org/doc/dist/faq.html#typicalprograms
"Eugene Zhuravlev" <jeka@intellij.com> wrote in message
news:aqbr2n$jbd$1@is.intellij.net...
>
>
think
>
>
>
>
Chris,
Thanks, we sure know about these resources. We are wondering how you
would like to use aspects in your real applications in addition to what the
PARC guys write.
Eugene
"Chris Bartley" <spam@feynman.org> wrote in message
news:aqbvai$pso$1@is.intellij.net...
at:
>
>
>
>
>
AOP is still very new. As far as I am concerned I am still learning it and I would be the wrong person to ask for ways to use AOP. Beyond the general goal of encapsulating cross-cutting concerns or using aspects to simplify testing I won't be of much help to define specifically how I would use aspects in IDEA. The AspectJ people should be the subject matter experts.
However since I know a few things about AOP (enough to be dangerous) this is my list of AOP related features in order of priority:
1.. aspect syntax support
2.. aspect weaving integration in project definition (what aspects to weave on what files)
3.. aspect support in debugger
4.. editor support for annotation of java code impacted by aspects (somewhere between the little i of implements in the gutter, the change highlighting with a VCS plug-in, and folded node tool tip)
5.. navigation between aspects and impacted classes (2 ways) (Goto Class/ Find usages like)
6.. refactoring support in aspects code
7.. refactoring Introduce Aspect (I am not sure what that would entail but it sounds really nice ;)
Cheers,
Jacques
BTW: I really think that AOP is going to change the way we develop. Do not mistake the fact that I am still learning AOP as a sign that it isn't important in my mind. I believe it is the OO of the 2000s. I just think you, with the help the AspectJ people, should take the lead on how to provide the best aspect friendly IDE.
As usual you can count on us to give you feedback as soon as you deliver something on the EAP. We will all learn together.
"Eugene Belyaev" <beg@intellij.com> wrote in message news:aqc1av$stp$1@is.intellij.net...
hi eugene,
most important would be syntax highlighting for advice & pointcuts +
compilation.
also good would be navigation support such as described in
(http://aspectj.org/doc/dist/devguide/rn02re04.html):
"When working with aspects, it helps to be able to navigate between
different program elements:
a.. When looking at a method, find the advice that affects it.
b.. When looking at a pointcut, find the advice that uses it.
c.. When looking at advice, find what it advises - e.g., method calls or
executions, initializers, etc.
d.. When looking at a type, find any aspects that declare members or
supertypes of the type, or vice-versa."
Please integrate aspectj support soon!
(maybe first (quick) on a plugin basis and as part of the core ide later?)
i don't want to go back to jbuilder or switch to eclipse because of their
aspectj support!
thanks
regards
matthias
"Eugene Zhuravlev" <jeka@intellij.com> schrieb im Newsbeitrag
news:aqbr2n$jbd$1@is.intellij.net...
>
>
think
>
>
>
>
I want to clarify a bit my original questions:
What we really would like to know now is aspects use cases. What aspects
use-cases and applications you can think of?
Suggestions for the aspect-support features, that are posted in this thread
are important and useful, but for better support it is also very important
to know the ways supported technology is used. We are aware that AOP is
still a very young technology. We examined aspect use cases that AspectJ
team published. Now we are very interested in hearing your opinions and
ideas about how aspects may be used. This includes both kinds of aspects:
1.development aspects (logging, testing, invariant checking).More?
2. aspects by design.
The more detailed the use-case is described, the better.
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Eugene Zhuravlev" <jeka@intellij.com> wrote in message
news:aqbr2n$jbd$1@is.intellij.net...
>
>
think
>
>
>
>
I would often use:
1. logging aspects.
2. some aspects for simple profiling
- function calls count
- call count by caller
- timing of function
- etc
Eugene Zhuravlev wrote:
Distribution, persistance, synchronization. As an example, take
synchronization. You could synchronize classes that were not originally
written for synchronization. Maybe these classes' and their signatures
are used in various places and therefore committed to. AspectJ
potentially allows you to add synchronization to these classes without
muddying up the original source code with concurrency concerns, without
even touching the orginal source code. With the power of AspectJ, the
development process could evolve such that inexperienced coders can now
write concurrency-oblivious classes while the more experienced
programmers write concurrent Aspects to apply to those classes.
Jon
And what about distribution?
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Jon Steelman" <steelman@mindspring.com> wrote in message
news:aqdvjg$na8$1@is.intellij.net...
aspects:
>
>
>
Using AspectJ to handle distribution allows you to avoid fusing the
distribution concern with the class. The aspect can control how data is
serialized and how much of that data is serialized depending on need.
Sophisticated distribution policies can be a detail that doesn't muddy
up the core class. Why would anything beyond basic serialization be
useful? Under certain circumstances, only a small fraction of a large
object needs to be serialized instead of the entire object. Using
AspectJ you can decide how much of the object should be serialized under
different circumstances. A goal like Doorastha's can be achieved:
distribution-transparent programming in Java. Like any other
cross-cutting concern, the distribution experts can take care of
distribution concerns while other programmers don't need to think about it.
Jon
Eugene Zhuravlev wrote:
>>Eugene Zhuravlev wrote:
>>
>>>What we really would like to know now is aspects use cases. What aspects
>>>use-cases and applications you can think of?
>>>Now we are very interested in hearing your opinions and
>>>ideas about how aspects may be used. This includes both kinds of
>>
>>>1.development aspects (logging, testing, invariant checking).More?
>>
>>Distribution, persistance, synchronization. As an example, take
>>synchronization. You could synchronize classes that were not originally
>>written for synchronization. Maybe these classes' and their signatures
>>are used in various places and therefore committed to. AspectJ
>>potentially allows you to add synchronization to these classes without
>>muddying up the original source code with concurrency concerns, without
>>even touching the orginal source code. With the power of AspectJ, the
>>development process could evolve such that inexperienced coders can now
>>write concurrency-oblivious classes while the more experienced
>>programmers write concurrent Aspects to apply to those classes.
>>
>>Jon
>>
I bet the aspectj.org email lists or newsgroups (whichever they have)
would be another great place to ask this question.
Jon
Eugene Zhuravlev wrote:
>>Hi EAP-members!
>>
>>A lot of votes have been given to the AspectJ support feature:
>>http://www.intellij.net/tracker/idea/viewSCR?publicId=2424
>>
>>Could you share we us your thoughts about Aspect applications you may
>>about?
>>Why would you like to use / not to use aspects in your code?
>>Any comments are welcome.
>>
Persistence. Crosscutting getters and setters to mark objects as dirty, and implement read/write locks.
One of possible AspectJ applications is support of Design by Contract (preconditions, postconditions, class invariants).
Links:
http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&q=designbycontract
http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=designbycontract+aspectj
http://developer.java.sun.com/developer/bugParade/bugs/4449383.html
(#7 Java RFE at http://developer.java.sun.com/developer/bugParade/top25rfes.html)
"Eugene Zhuravlev" <jeka@intellij.com> wrote in message news:aqbr2n$jbd$1@is.intellij.net...
>
>
>
>
>
>
I can say that since the technology isn't a tried and true one we will concentrate first on the development "aspects":
1.. Facilitate debugging with weaving of logging output
2.. Virtual mocking of object: this aspect could be a very important one for us and my way to introduce AOP in my organization, because of the difficulty of unit testing software that hasn't been designed for testability (we call them "legacy"). The fact that you can intercept any calls will make creation of mock very simple making unit testing a breeze.
http://www.xprogramming.com/xpmag/virtualMockObjects.htm
http://www-106.ibm.com/developerworks/java/library/j-aspectj2/?loc=j
Jacques
"Eugene Zhuravlev" <jeka@intellij.com> wrote in message news:aqddos$qak$1@is.intellij.net...
Rickard
Rickard Oberg has some thought about aspect oriented programming in Java which I find interesting. His taking a different approach than AspectJ that doesn't require precompilation. His been using dynamic proxies and he is about to make this framework available as open source (I hope).
There is a video at JavaBin (http://www.java.no) he talking about this framework.
There's also a thread at JBoss on including this framework in the JBoss server (couldn't find the link on Oberg's site).
www.dreambean.com
Most of the AOP discussion happened in october....
PS: Couldn't write Rickard's correct name because the message got broken.....
Ya, I've been reading Rickard's blog, and he has some really interesting ideas. I think he's an Intellij fan, so maybe send him an email with this question ;o)
The hints he's dropped about his AOP framework have been pretty tantalizing. I'd love to have both AspectJ and his stuff, when it comes out. (Maybe i'm pushing the bleeding edge here a bit. ;o)
Anyway, most use cases for my attempts at aspects have been logging, metrics and validation. I also had an interesting idea that I never got working well that involved System properties, and intercepting various calls to such, sort of a roll your own ACL... Maybe if I didn't have to use eclipse to develop it... heh heh heh.
I'd love a "Convert to aspect" refactoring, sort of a combo of find usages and extract method. It sould strip out the highlighted cross cutting concern in every method where it is used, and replace it with a joinpoint instead of a method call. If that's a little complex, maybe have this only apply to one method call (method call disappears, joinpoint appears...)
I'd also really like it if intellij had aspect annotations noted somehow, either in the gutter or the code itself, as well as call-stacks for aspects, and call-stacks for regular java methods that included aspects.
Uses / Notes:
1) Runtime assertions/Sanity-checks (req. conditional build feauture with/without use of aspects).
2) Compile time warnings/errors (this class may not be called by this class an so on)
3) Fun instrumenting core Java classes or 3rd-lib classes with/without source.
4) Writing all aspects as *.aj files (I really HATE using .java extension for aspects).
Here is a concrete example. In my application, I have a "ConnectionFinder" class which manages the distribution of jdbc connections. This, of course, distributes java.sql.Connection objects, some of which come from a connection pool, and some of which do not, depending on the context.
I would like to keep track of all connections which are distibuted and what is being done with them (e.g. get a list of all open connections and their open resultSets). Unfortunately, the java.sql.Connection class doesn't really give me much information about the current state of the connection (i.e. I can't call "getAllOpenResultSets()" on it). In addition, I'd like to be able to make sure that all open result sets get closed when a Connection gets closed (since closing a Connection doesn't always close result sets if the Connection is coming from a pool).
So, I would like to build an aspect which will
intercept all calls on the Connection objects and keep track of what is happening. I can do this by wrapping a Connection and implementing the interface, but I get in trouble when I want to compile on both jdk1.3.1 and 1.4.1, since the Connection interface has changed beween the versions. An aspect would solve this problem perfectly.
John
The aspect user list has a similar thread going on right now.
<http://aspectj.org/pipermail/users/2002-November/date.html>
look for "Examples of using AspectJ"
Eugene,
Make sure that you make your existing refactorings Aspect aware!
Since aspects pointcuts are naming patterns, changing the signature of a
method might cause an aspect to not be weaved anymore or a new one to be
weaved. At the very least you should warn about it and do nothing like the
current refactoring warnings.
A more difficult but more powerful approach in the case of removing an
aspect weaving, is to refactor the aspect pointcut to make sure the aspect
still applies. I haven't explored all ramifications but one that comes to
mind is: what about the other weaving points of the refactored aspect,
should they be refactored too? This could be a very nice mass refactoring
based on naming patterns identified in aspects which BTW should be one of
the Aspect refactoring I talked about in another post.
Refactoring a pointcut would also refactor the classes impacted by the
pointcut aspects (potentially cascading to other aspects in the case of
pointcut duplications)
BTW is anybody interested in writing a paper on Refactoring and Aspects?
Jacques
"Eugene Zhuravlev" <jeka@intellij.com> wrote in message
news:aqbr2n$jbd$1@is.intellij.net...
>
>
think
>
>
>
>
My aspect uses during development of application:
- Performance testing
- Debugging / Tracing execution
- Code analyzing during test runs
What do you mean by " - Code analyzing during test runs"?
--
Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"
"Juhana Riihim?ki" <jiveadmin@jetbrains.com> wrote in message
news:5163222.1038656771566.JavaMail.jrun@is.intellij.net...
>
Eugene Zhuravlev wrote:
You can design "programming rules".
Example:
Given is a client / server application. Server offers services in
several classes. There could be a rule: "No unchecked exception should
be returned by service methods. Instead a InternalErrorException
(derived from Exception) should be thrown." Code of service classes
could look like this:
pubplic void aServiceMethod() throws InternalErrorException, ... {
try {
// do service
} catch (RuntimeException e) {
// logging, rollback, mapping to InternalErrorException, ...
} catch (Error e) {
// logging, rollback, mapping to InternalErrorException, ...
}
}
Try catch block always has to be copied. The only thing can be
simplified is to extract error handling (logging, rollback, ...) in a
common method:
pubplic void aServiceMethod() throws InternalErrorException, ... {
try {
// do service
} catch (RuntimeException e) {
doErrohandling(e);
} catch (Error e) {
doErrohandling(e);
}
}
Cut and paste is not nice and can be forgotten ...
Glen
Less focus on AOP, which is a technique which should have its own language instead of piggy-backing on top of an OOP language.
More focos on something like Generics, which will actually make it into the core Java spec sooner or later.
Completely agree.
Completely agree.
From Generics everybody would benefit. The advantages from AspectJ are
questionable.
Tom
Well, it seems to be a pretty popular feature request, with well over two thousand votes. If you want generics, cast your votes for that feature. I have. In any case, they're both high priority items.
http://www.intellij.net/tracker/idea/viewSCR?publicId=7090
On the other hand, I think AspectJ and AOP are very useful tools, and would love to get them integrated into IDEA. I would find them much more useful than generics.
Also, could you please expand on your objections to aspects, and why their advantages are dubious and less useful than generics? I really am curious, and am not just asking this facetiously...
--pete
On Thu, 05 Dec 2002 00:24:47 +0000, Peter Morelli wrote:
It would seem more logical to have the AspectJ support as some form of
plugin, than in the core Idea, as its not part of the core Java language.
Sorry, but I would not count the votes too much, because one can
create a dozen accounts and vote with hundret points for an issue.
The problem with AspectJ seems to be (at least for me), that nobody
showed a useful, explained example. In the opposite, all developers
use collections and definitely would benefit from type-safe
collections (aka "Generics").
Maybe I'm just missing the key-point of AspectJ...
Tom
"Thomas Singer" <idea@regnis.de> a ?crit dans le message de news:
3df06c6a.3476949@news.intellij.net...
>
>
I definetely agree with you.
As it's soon Xmas, it makes me think that AspectJ is a kind of new toy that
all children'd love to have, but wouldn't really play with.
Whereas, on the other hand, Generics is what they'd really use in their day
to day job.
But unfortunately, Generics has less buzzwords attached to it, less shiny
sparkling stars around...
Guillaume