AspectJ in 8.0?

FollowFollowed by 5 people

Hello Robert,

First of all, congratulations on IDEA 7. It includes some much
appreciated features.

However, for me, there is one major feature that IDEA is missing,
namely (full) AspectJ support, such as the AJDT for Eclipse. I feel
AOP, and not just for Spring beans, is the greatest innovation for
quality/production enhancement since Object Oriented Programming.

Will there be done work to have full support for AspectJ in IDEA 8.0,
including the visual aids that are so necessary?

While we're still in the planning stage for the 8.0 release, we don't currently
plan to provide full AspectJ support.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Hello Robert,

First of all, congratulations on IDEA 7. It includes some much
appreciated features.

However, for me, there is one major feature that IDEA is missing,
namely (full) AspectJ support, such as the AJDT for Eclipse. I feel
AOP, and not just for Spring beans, is the greatest innovation for
quality/production enhancement since Object Oriented Programming.

Will there be done work to have full support for AspectJ in IDEA 8.0,
including the visual aids that are so necessary?

Out of curiosity, what kind of aspects do you use?

As you menttion, IDEA 7.0 has good support for the AspectJ subset that is
used by Spring AOP.

-tt

Out of curiosity, what kind of aspects do you use?

Aspects on the domain model, considering those are normally not managed by Spring beans.

For example the classic example where you have a requirement that listeners are notified when an object state changes.

By using aspects you can generate a compile error if the listeners are notified by something else than the defined aspect, and advise the state changing methods to call the notify listeners method.

If IDEA can do this, but just missed this functionality, then I would really like to know how.

While we're still in the planning stage for the 8.0
release, we don't currently
plan to provide full AspectJ support.

Dmitry, I think it would be a very good move for JetBrains if you decide to support it.
I know there are many people who use Eclipse, because of the AspectJ support, but would prefer to use IDEA because of the superior Java coding support.

I would please ask you to consider supporting AspectJ, to give the full power of AOP to the developers.

Any other people who want to support me on this request?

I feel AOP ... is the greatest innovation for quality/production enhancement since Object Oriented Programming.

Well that's clearly not the case. Everyone here knows that that honor is held by automated refactoring and inline static analysis. :)

--Dave Griffith

Hello Robert,

>> Out of curiosity, what kind of aspects do you use?
>>

Aspects on the domain model, considering those are normally not
managed by Spring beans.

Ok, I'd be interested in some more details:
-What kind of weaving do you use? If LTW, are using using Spring LTW support?
-What features of AJDT are most valuable in general? Which ones do you never
use?
-If your team had a discussion before choosing to apply "full" AOP, what
was the deciding argument to do so?
-Any specific/interesting AOP patterns you are using?

For example the classic example where you have a requirement that
listeners are notified when an object state changes.

By using aspects you can generate a compile error if the listeners are
notified by something else than the defined aspect, and advise the
state changing methods to call the notify listeners method.

So, I assume you're using two aspects here:
-one to transparently fire modification listeners from any setter
-another to trigger compiler errors when someone calls fireListeners() directly

I think that triggering compiler errors from an aspect is not related to
AOP at all. It is a clever reuse of the infrastructure by the AspectJ developers.
But is seems this is just a repurposing of the tool as a "domain-specific
code inspection language".

Can you give some more (and more advanced) examples?
I assume you haven't switched to a verdor-specific toolchain only to have
modification listeners transparently fired?

-tt

+I feel AOP ... is the greatest innovation for
quality/production enhancement since Object Oriented
Programming.+

Well that's clearly not the case. Everyone here
knows that that honor is held by automated
refactoring and inline static analysis. :)

:) Fair enough. But I hope you agree it would be great to have it in IDEA.

Hello Robert,

>> Out of curiosity, what kind of aspects do you use?
>>

Aspects on the domain model, considering those are

normally not

managed by Spring beans.

Ok, I'd be interested in some more details:

It is good that you want to know more, but unfortunately my knowledge and experience is limited. Because IDEA does not support AspectJ, I do not use it professionally yet.

So when you ask me what would be the deciding factor for using full AOP for my team, then I can simply say that it is not an option yet, because IDEA does not support it.

I can say however that I usually prefer things that can be done compile time.

For example the classic example where you have a

requirement that

listeners are notified when an object state

changes.

By using aspects you can generate a compile error

if the listeners are

notified by something else than the defined aspect,

and advise the

state changing methods to call the notify listeners

method.

So, I assume you're using two aspects here:

No, it's in one aspect.

-one to transparently fire modification listeners
from any setter
-another to trigger compiler errors when someone
calls fireListeners() directly

Can you give some more (and more advanced) examples?
I assume you haven't switched to a verdor-specific
toolchain only to have
modification listeners transparently fired?

I think you are missing the point. Sure it is a simple example, but the implications are big.

We have one requirement here that listeners are notified when an object state changes. Instead of having to implement this in many different places, you can implement this in one place!
What's even better is that when you get a new requirement, that forces you to add a new method or a subclass, you don't have to take into account the previous requirement about the listeners.

So in general AOP is useful when you have a single requirement which forces you to implement it in many different places with normal OOP, and which you have to take into account with implementing any new requirements.

Now in practice this could be many things only limited by your imagination :)

AOP, sure. AspectJ, I'm less convinced. There's many chances to screw up between "powerful programming model" and "usable production programming language", and it feels as though AspectJ has hit a lot of them.

--Dave Griffith

AOP, sure. AspectJ, I'm less convinced. There's
many chances to screw up between "powerful
programming model" and "usable production programming
language", and it feels as though AspectJ has hit a
lot of them.

That's always the risk, but powerful tools can always be misused. I don't think it should stop us.
I would be happy with any AOP that can be used on something else than Spring beans. It doesn't have to be AspectJ necessarily. I'm flexible.

I'm in the same boat. I can't (won't) really use AspectJ until IntelliJ supports it. I've always thought the the AspectJ situation with IntelliJ has been somewhat of Catch-22: JetBrains won't put AspectJ in because it's not widely used, it's not widely used because IntelliJ doesn't support it (yes, I've tried Eclipse; first I hate Eclipse, second, between being a AOP beginner and a half-assed tool, it was taking me way to long to figure out how to solve even the simplest of problems).