AspectJ 1.2, the AO extension to Java, has a second release candidate out of door. Version 1.2 provides major improvements to the functionality of the supporting tools and enforces some language limits that went unchecked before. It also has significant performance improvements.

Read more about AspectJ 1.2

Related News: Adrian (AspectJ lead) had some interesting ideas for dynamic pointcuts with AspectJ. Read AspectJ, "dynamic" pointcuts, and Spring. A great combination

From an academic point of view, AspectJ is very interesting. Commercially, it would have to be broadly supported and integrated to be really viable. What is the prospect of AspectJ features making their way into Java? There is no JSR, right?

I tend to think that Aspects are too immature a technology to be smacked with a standards bodies yet. There are compatibility efforts going on, but too much actually new stuff is still being done to define a non-stifling standard for much of it, I suspect.

That said, I am just an interested user, not an implementer, so who knows.

-Brian

From an academic point of view, AspectJ is very interesting. Commercially, it would have to be broadly supported and integrated to be really viable. What is the prospect of AspectJ features making their way into Java? There is no JSR, right?

That's interesting, I would have thought it would be exactly the other way around. I know my college professor would absolutely blow a gasket if he learned someone could reach into his code and prevent methods from executing, for example. Isn't academics about proofs and theory over coding?

But in real world applications, getting it done is priority #1. Of course, my money is nowhere near my mouth on this one...

That's interesting, I would have thought it would be exactly the other way around. I know my college professor would absolutely blow a gasket if he learned someone could reach into his code and prevent methods from executing, for example.

But would he perhaps like it if realised he had the ability to slot in additional functionality without code changes? AOP can give some quite elegant solutions to monitoring and tracability and those other common cross cutting concerns. Wily Technology have been using AO to allow them to slot in monitoring ability with their product for quite a while, so the monitoring/tracing can come later.. Definately a technology to watch. But like I've said before, it'll probably take some time before we get something meaty in terms of *real* innovative use for AOP (ie something beyond logging/persitance and tracing

regards,
Nathan Lee

it'll probably take some time before we get something meaty in terms of *real* innovative use for AOP (ie something beyond logging/persitance and tracingregards

Read "AspectJ in Action" for more examples.

Maybe we need to learn to think in aspects before we can discover all the possibilities of AOP.

Thats sort of a chicken and egg answer, isn't it? Let me paraphrase:

"I'm interested in AOP. What can it do for me?"

"Go buy a book."

"That sounds good.. and it looks like a good book from the sample chapters, but I still want to get an idea what it can do for me before investing the time and money in the book."

"Um. The reason for buying the book, is in the book."


So.. perhaps one problem with AOP is that the only examples that are public are tracing, logging, debugging, and the like? If people could publicise some other real world problems and solutions with AOP, that would help drive more interest in the area. I know I would personally like to see some other solutions and ideas floating around.

...perhaps one problem with AOP is that the only examples that are public are tracing, logging, debugging, and the like...

These examples IMHO actually represent issues that AOP is trying to solve through separation of concerns.

A typical server-side application keeps a lot of "tracing, logging, debugging" code along with the business core of the application. Nowdays it's a necessary evil, yet in a dream-world it would be great to have those orthogonal pieces developed, debugged and tested separately, and weave together on as (and where) needed during deployment. So when the business method is called this fact is logged, when a restricted function is invoked am access aspect intercepts the call and throws an exception, yet not a single non-business aspect of the application is present in business methods.

In orther words (INHO) the mere ability (and advantages that stem from having) not to manually weave orthogonal concerns into business logic during development justifies researching an approach that provides means for writing better (more mainteinable) applications.

I do like the idea of externalizing much of the normal tracing/logging/debugging messaging that goes on, and leaving the core business code cleaner. However, two things I would say are:

- Although I like the ability to pull it out, it's not such an overriding problem or concern that I want to shift to a whole new system. Log4j is pretty easy and low overhead.

- I understand that the ability to cross-cut the code is interesting.. I'm just saying that it would be a good idea to bring out some best of breed examples, concepts, or other ideas to show users how this would be useful to them. Outside of the logging/tracing worlds. How are people using this now to solve business problems.. enhance applications.. etc?

Senior developers have more power than junior developers. But often they are not open minded to new, good ideas like AOP. Thats my experience as a junior developer. In the IT world nothing is so fast outdated like "experience". Senior developers often are burnt out. They often stopped to like their job. So they don't look for new things. They are simply not interested in new things. As I said, that is the experience of myself and surely not represantative for all senior developers. I thank god if I will not become like these people ...

My project leader dismissed my proposal to use AspectJ. He nearly doesn't know anything about it. But still he dismisses it. I told him the many advantages. He is like someone who is afraid of waterbeds for no reason.

One application of AOP can be to replace application servers. All the things they provide can be implemented as aspects I read. You can weave your application exactly like you need it. Its made-to-measure.

AOP and log4j don't exclude each other as someone wrote here. Its because in traditional programming, logging is spread over many methods and classes, even if log4j is used.

Maybe OOP had the same problems of justifying itself earlier.

Senior developers have more power than junior developers. But often they are not open minded to new, good ideas like AOP.

See, that's the problem: if you think it's a good idea, you need to convince him. He might think it's a bad idea and have a point, did this occur to you?

Hell, even I would be hesitant introducing AOP in a project, and it's not because I don't understand it nor because I don't think it's a good idea. There are many other factors involved in such a critical decision, and junior developers typically tend to not see the bigger picture. Which is one reason why they're junior :-)

I thank god if I will not become like these people ...

Oh but you will.

--
Cedric

I know my college professor would absolutely blow a gasket if he learned someone could reach into his code and prevent methods from executing, for example.

One of the situations I've always wondered about is that anyone with access to the bytecode could now tweak and redefine the flow related to licensing constraints and authorisation enforcement. I am sure a lot of business managers are likely to blow their gaskets thanks to this. Having code that was potentially decompilable was bad enough. Having a capability to be able to change licensing and authorisation flows with a little decompilation and adding some introductions could just make security enforcement a little harder. Ditto for business processing flows as well.

Add runtime bytecode modification / dynamic pointcuts and the flow could be modified without any making any changes to the .jar on the disk (so verifying the checksum on the .jar alone will not suffice). Seems like we're going to have to secure and continuously verify all the elements in the classpath.

Am I being just too paranoid here or is AOP going to require some enhancements to the way we enforce security ?

Dhananjay

This is a good point, but this kind of thing can currently be done without AOP easily. There was an article on TSS a week or so ago on "patching core Java classes." Just decompile, edit, and update.

This is a good point, but this kind of thing can currently be done without AOP easily <..Snip..>Just decompile, edit, and update.

Agreed, but AOP makes it more difficult to detect such malicious modifications. A simple checksum verification on the jar would give away the above change.

There is no JSR as such, but AspectJ is widely regarded as the reference implementation. It's definitely one of the more mature/powerful AOP frameworks out there. I think the focus with AspectJ now is more on making it easier to use.

There isn't a JSR for AOP, the only attempt at standardisation is the AOP Alliance (on SF). However, there is a JSP for instrumentation which is the technique used by Aspectwerkz (and I think JBoss). It seems likely that other AOP implmentations would follow the same course as it allows developers to integrate AOP without affecting the existing build process, and offers greater control over DP AOP implementations.

The biggest problem with Aspectj, regardless of maturity/functionality is the fact that they chose to extend the language which makes it more difficult to integrate into existing projects. Development and build environments would need to be altered to fit it in, which seems overly expensive to me. What do you think tho Rory? How do you use AOP currently?

One example is our logging framework. We have a proprietary log format and the framework has been ported over from C++. Its performance is good, but generally for development, a log4j-style framework is easier to work with. So we have some aspects that intercept our logging calls and redirect them to the equivalent log4j calls. So you can get the flexibility of log4j during development, but then during production, you can switch to the more optimised framework. And you don't have to disturb any of the thousands of existing log points in there already. There's a lot more places where AOP could be of use, but the big problem I've found though is that there is a good deal of reluctance on the part of some senior developers to "trust" things like AOP. Some of them hate the thought of it. If you could convince those guys that it's a good approach, then you could get a lot more use out of it.

Sorry, didnt really answer your question properly :-)

AspectJ is OK for us, as we use Eclipse/WSAD almost exclusively, and the AJ plugin for Eclipse makes it easy. I can see how something like AspectWerks could be much more convenient though.

what are your senior developers concerns? Have they researched AOP or are their opinions based on just a gut reaction to the problem? Can't the junior developers, like yourself, demonstrate the benefit of such a design?

Well, I don't know about that Graham. As a relative newcomer to Java development, you might not be aware of the politics of software development in the workplace. But I tell ya, sometimes it's not an easy task to get everyone pulling in the right direction on these things!

rofl, I suppose if you'd come to me when your were a junior developer at our last company brandishing a handful of white papers about AOP in the enterprise I'd have been hesitent about it too!

On a more serious note, who was responsible for the choice of aspectj? Did they look at any other frameworks?

Well young man, as you well know, in your last position (as junior hot beverage production consultant) reporting to the senior architect (me), you need a good business case for these things! How the years go by so quickly, eh!

...you need a good business case for these things!

It's a huge advantage to have a success story/stories available at the time of making architectural decisions that involve new technology. Yet, more often then not, when a technology proof is readily available a project is stuck with yesterdays decisions that are "impossble" to rollback.

Provided there is some lax in budget and some signs that new technology might be really useful in the long run, in a typical scenario a pilot might be created to make a case for yourself whether it is worth persuing the technology, what are tangible and intangible benefits (of any). Pilots also introduce patterns for the use of the technology to a team and serve as the best (in-house, always available and adaptable) examples.

doesn't pilot.equal(job/2)? Add some white paper research and that'd be a great one for a "senior" developer like Rory!

I agree with the principal, the only problem with Rory's situation is that there is a large existing code-base. AOP is something that should really be introduced at the conception of a project, adding something as powerful as AOP unless it's a DP implementation, can be a very risky decision, especially without comprehensive unit tests. But I belive that Rory and co have that in place so perhaps there is room to introduce into different areas of the project.

I agree with the principal, the only problem with Rory's situation is that there is a large existing code-base

That's definitely part of the problem, although some of it is cultural resistance. But I do think that a lot of that is changing. Unit testing is a good one though, we've talked about adding persistent test cases that perform the necessary database setup and cleanup via interceptors. Currently we've written a framework to handle this, but doing this initially (JUnit 3.7 or so) meant re-wiring some internal JUnit classes, so you break forward-compatability. With AOP,you could bolt this on more easily.

doesn't pilot.equal(job/2)? Add some white paper research and that'd be a great one for a "senior" developer like Rory!

Can I have tea please, with one milk, no sugar.

AOP is something that should really be introduced at the conception of a project, adding something as powerful as AOP unless it's a DP implementation, can be a very risky decision, especially without comprehensive unit tests. But I belive that Rory and co have that in place so perhaps there is room to introduce into different areas of the project.

Yes, that's where the proxy-based stuff is invaluable. It works. It's easy to understand. You can refactor easily to introduce it (for transaction management etc.) and lots of people have already done so with good results. Or of course you can use it to enable a POJO design up front.

AspectJ is a different animal. The benefits are potentially huge. But there's a way to go before it's going to be used widely. Yet I think it will be within 3 years.

Everything is risky without proper unit tests IMO.

R