Skip to main content

AspectJ

13 replies [Last post]
monika_krug
Offline
Joined: 2004-10-14
Points: 0

I would like to see the AspectJ language added to the Java language. It does not break anything, so nobody would be forced to use it or change any line of their code if aspects were added to Java.

AspectJ increases the expression power a lot with a small number of additional language constructs. It is just so ... neat.

I would like to be able to use join points in normal Java classes, not only in aspects.

I would like to use any Java compiler instead of being refined to the AspectJ compiler. E.g. for now it is not possible to use AspectJ together with J2ME. (Or is it, and I just could not figure out how to do it?)

Monika.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kirillcool
Offline
Joined: 2004-11-17
Points: 0

I've been reading quite a handful of materials about AOP and i have come to this quite disenchanting conclusion: it encourages bad programming practices that should be avoided at any costs.

Let's take two examples that are given in any AOP language, [b]logging[/b] and [b]context passing[/b].

AOP takes pride of the fact that it allows "injecting" code at the beginning and at the end of any method (specified using sophisticated "regular expressions"). But does this really qualify as a logging and tracing mechanism? Not really. Any non-academic application has functions with multiple exit points (although this on itself can be called a bad programming practice) with multi-branch logics inside. Typically I would have 5-8 log points with various log levels. The important lines that i wish to log most certainly lie inside the code. Each line prints information on specific objects. Moreover, these messages must be localized using DB (or configuration XML file) and filtered based on the log level that can change [b]at runtime[/b] (presumably after an erroneous behaviour is spotted). AspectJ most certainly does not provide any means to do this.

Second, [b]context passing[/b]. Now we have a stack of 10 functions and we need to pass additional parameter to the innermost function. Now we have two cases: there are already way too many parameters and we don't want to pass an additional one (this is called [b]not modular[/b] in AspectJ tutorial); or we have some class that contains all the arguments and we are too lazy to change it.
The second case is obvious - it costs next to nothing to put an additional member to this class without breaking the modularity. The first one is more tricky. If you have already 15-20 parameters for each function, than your coding practices really suck. If you are unwilling to add a parameter to a function that doesn't really need it, but has to pass it to another function that does, you should rethink the design of your functions. In any case, "pushing" a parameter into a code that wasn't designed to handle it is very bad design. Moreover, this forces reading multiple files in order to understand what each function does.

Another examples of AspectJ from the tutorial in short:
[b]pre and post conditions[/b] - should really be a part of the methods (especially in Java where you should be able to read the Javadocs to understand what is the contract and when the exceptions are thrown)

[b]contract enforcement[/b] - covering up for a bad design.

[b]configuration management[/b] - via standard resource bundles, property files and Ant configuration.

Kirill

jhook
Offline
Joined: 2004-07-15
Points: 0

I know a lot of developers are "warming" up to AOP and what it has to offer, but I've become increasingly disenchanted by the whole idea.

What ever happened to type safety, readability, and test driven development? Things like the composite pattern, decorator pattern, etc can offer the same kinds of features that AOP offers, but with the type safety and readability.

If I can't 'new' it in a main method and run some tests, I'm not really interested in using it in implementing any logic.

The concept of Mixin's are nothing new-- Java can already do that with the composite pattern in a well defined manner. Interceptors are useful for the reasons described in any AOP introduction, but are only really applicable in a framework (Servlet Filters, etc).

Some use the example of debugging with AOP, well, if you didn't use AOP in the first place, you would probably be able to debug your code within your IDE's debugger without needing to write any extra code.

I would be interested in hearing how people are using AOP in their applications and why?

monika_krug
Offline
Joined: 2004-10-14
Points: 0

What makes you think AOP reduces type safety?

Monika.

dragand
Offline
Joined: 2004-06-10
Points: 0

Maybe this project could offer an example of using AspectJ that is not in the scope of usual logging example.
Project link is http://e-nspire-gemini.dev.java.net (more info is available at http://gemini.e-nspire.com )
It enables bidirectional relationships in plain Java - feature previously available only in EJB or other containers.
Best of all - users do not need to know AspectJ 5 due to new AspectJ annotation-based pointcuts.
In this case, a lot of handcoding or container dependency is replaced with a relatively simple library that is extremely easy to use.
The only drawback is that it requires AspectJ, so it would be easier if JVM have had some AOP features... Anyway, adding AspectJ does complicate only build process (due to the need for weaving), but in runtime it is as simple as runing any other pure Java program.

jwenting
Offline
Joined: 2003-12-02
Points: 0

And while we're at it, add JUnit, Apache, Geronimo, Jython, JRuby, Xalan, Xerces (ok, that's already there but another XML parser never hurts), and every other project and library on the net to the core API.

Of course the codebase will grow with another few million classes, but there must be someone using each of them so it's worth it right?

tsinger
Offline
Joined: 2003-06-10
Points: 0

I've heard a lot of people say "AOP is a very cool stuff, you can do very good things". Unfortunately until now I only saw an example, which illustrates logging. Hmm, nothing, that I couldn't do with existing Java.
Could somebody please shed some light on me, what other, really cool stuff is possible?

Tom

monika_krug
Offline
Joined: 2004-10-14
Points: 0

See the AspectJ Programming Guide - Getting Started with AspectJ: www.aspectj.org -> http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/doc...
The first chapter concentrates on what can be done with AspectJ.

Monika.

opinali
Offline
Joined: 2003-06-17
Points: 0

My suggestion: the people behind AspectJ should just start a JSR to produce an official JCP standard for AOP in Java. This shouldn't be very hard, AspectJ is already pretty mature, although other AOP tools like JBossAOP might have to be considered.

But please don't add any of this stuff to the JRE. I'm not sold on Aspects, but it's not just my opinion -- Aspects are *far* from being popular enough to deserve a place in the J2SE core.

denka
Offline
Joined: 2003-07-06
Points: 0

I'm not sure you have the full understanding of all adversities this would have caused.
Apart from what's mentioned over there http://www.javalobby.org/thread.jspa?messageID=91812449&threadID=14633&f... (which did not even consider changes to language), also, every syntax extension has the potential of slowing language parsers down to the degree when it's unacceptable. Those using vi/EMACS could not care less, but providing code completion and on-the-fly syntax analysis in modern IDEs will (IMO) become too slow to tolerate.
I hope I will not be misleading anyone by offering as a proof of this the fact that creators of IntelliJ IDEA at some point integrated AspectJ support, but had to disable it.

monika_krug
Offline
Joined: 2004-10-14
Points: 0

I guess you may be right about the on-the-fly syntax analysis. I don't know about IntelliJ IDEA, but in Eclipse syntax parsing is recommended to be disabled when working with AspectJ.

But the article that you linked to mostly talks about changes to the JRE. AspectJ is a compile-time solution that requires no changes to the JRE.

Monika.

denka
Offline
Joined: 2003-07-06
Points: 0

This article presumes that idea of integrating aspects into Java has to be deep. If it's shallow (preprocessor), is it even worth bothering with? Then again, why bother (and trouble others) extending language if all the same can be expressed using the existing, mature syntax (as Aspectwerkz, DynAOP, others had proven)?

monika_krug
Offline
Joined: 2004-10-14
Points: 0

AspectJ is not a preprocessor, it's a compiler.

Why should aspects be included in Java? E.g. now AspectJ does not support generics and all the new things that came with JDK 1.5.

Monika.

denka
Offline
Joined: 2003-07-06
Points: 0

Now, why would you fix a problem that AspectJ is having by placing a heavy burden on Java platform? Either go bugging AspectJ folks, or use some other (more language-friendly) AOP implementation :)