AOP

The implementation of AOP I find most feasable at the moment is AspectJ, it's a pure java implementation and is catching up on tools quickly.

Some cool things that can be accomplished with AspectJ:

• Rule based transactions - a replacement for declarative transactions in ejb layer. With introduction of AOP it's questionable how much usefull ejb layer is in common j2ee architecture. Most likely the projects that already have the EJBs will continue to use them. For the new projects seems like an overkill to introduce the ejb's only for declarative transactions support when you can accomplish the same goal with AspectJ. The only reson you might still introduce the ejb container to the project if you plan to havily use MDBs. If the MDBs use is going to be limited, it should be replaced with some alternative approach.
• Maintaining open/close database connections declaritivly. It can be used not only for db connection maintenance, but for any type of external resource that is managed throught the pool, or lives with in init/cleanup life cycle. Traditionally projects have all sorts of policies and recomendations that are very hard to follow and impossible to enforce. Very quickly open and close logic is spread through out different method calls when it really whould be tightly balanced and incapsulated with in single method call. In this case AOP is the most feasable chose.
• Custom Security Implementation. There are many systems architected without much security thought upfront. Some times it is not a trivial task to bundle security into already written system. AOP is the answer again. Without rearchitecting the whole solution, we can achieve the desired results (minor refactoring might still be necessary). Even when working on new system, AOP might be a good alternative to other security architectures. It's ultimately flexible and allows to truly decouple the Security from the Business logic (just the way it should be).
• Passing context/state information between layers. Database connection can be passed through out different method calls without polluting every method in the system with the connection object. It's hard to know ahead of time wich method will need the connection, wich wont. Sticking the objects in the http session is not a great solution - sort of works, tends to be less maintainable on the long run. The AOP solution could be a bit sophisticated to implement, but will yeld better results on the long term.
• Implementing true Multiple Inheritance in Java. Use at your own risk.
• Code policing. It's specially important on big projects (10+ developers) when all players have different level of expirience.
• And of cource method trace logging. It's painfull to watch people injecting tracing code in every method on the project. This task can be totaly automated and turned on and off on demand with AOP.