JSR 175 Annotations are still getting a lot of buzz in the community (and at JavaOne). This article discusses the use of meta-programming in a given use case. The example mixes the use of annotations AND byte-code instrumentation.

Conclusion

In this article, I have replaced a hard-coded solution with one that uses meta-programming based on annotations and instrumentation. Although I've eliminated the need for any extra steps in our build process, my solution still has a number of limitations. In the next installment, I will explore a completely different implementation that uses thread sampling, and then combine these two techniques to create a solution that gives the best features of each. I will also discuss a number of additional requirements, including a progress bar and dynamic status messages.

Read Attribute-Oriented Programming with Java 1.5, Part 1

Not another AOP! ;)

Just had a quick scan at the article, looks interesting enough for me to actually spend more time on looking at Java 5 (LOL ;-) ).
But a possible problem that could (will) happen when "standard" Java development goes this way is compile time checking v.s. runtime checking where I prefer the first. Espescially with less-experienced programmers.

I need more coffee :-)

Thanks for the article, really good detail there.

If I was running the project and a programmer put this into the build, I'd definately spot a techie at play. And make sure there was a very simply way to strip it all out.

The initial excuse for attributes was that the string was hardcoded in many places. This is what constants are for - or better yet some resource bag with constant lookup.

The byte code instrumentation is educational - ie how relatively easy it would be to dive into this stuff. But I have a huge problem with instrumentation - it means that my code is no longer deterministic. i.e. what is programmed is no longer what is run. I can imagine horrible race conditions where the instrumented code works and the non instrumented doesn't. I also fear for complexity - where the brighter team members hack in loads of this stuff and then leave. The maintenance coders are then left with a code base which is in no way tied to the runtime. In effect you have changed the semantics of the language, and the jvm. It may be cool but it isn't safe (IMHO).

I also recon that logging is in fact good enough. Also interfaces can be extended to include a logging layer as required - just some care in the initial project phases. As with aop we have a great deal of technology with many risks being used to solve 'logging' (ok a gui status bar). This stuff is simple and doesn't need such a solution. Can anyone think of a use which is not logging/status or login/permissioning?

Thanks again.

Jonathan

There is more use cases than status bar like data access or security(it was an article about cache and asectj last week). BCEL is one of ways to implement "declaratyve aspects". You can get idea how to execute SQL and to process result sets from http://voruta.sf.net, any attribute enabled AOP framework can do the sane too (I found it is very trivial to implement it at home) I use some of this stuff in production without problems.

The initial excuse for attributes was that the string was hardcoded in many places. This is what constants are for - or better yet some resource bag with constant lookup.

Yes, originally there were all these nasty ugly horrible hardcoded strings in the source code. But now things are all better, you see, because those same horrible harcoded strings now have @status in front of them :-)

Interesting idea but it would take just a few lines of code with any AOP framework...

Also, the problem with this approach is that it involves several "levels" of Java programming:

- Bytecode tweaking
- Normal Java programming
- Meta Java programming

I would argue that it's a lot for regular Java developers to handle...

--
Cedric

This stuff is simple and doesn't need such a solution. Can anyone think of a use which is not logging/status or login/permissioning?Thanks again.Jonathan

This is what my opinion as well!
What problem exactly AOP is trying to solve? In a large code base, maintainig code itself is difficult enough. Now you have to maintain aspect as well.

And the code is manipulated at runtime. So, What You See is NOT what you Get.

May be for logging and little things this might be good. But for more complicated systems, aspecting will create more problems rather than fixing (anything at all).

And annotations, I am hitting the same problem again. What exactly its trying to solve??

Very well written. A lot of information presented in a concise and understandable way.

The link to the sample code in References is broken.

>@Status("Connecting to database")>public void connectToDB (String url) {...}You will want the url in the status message. Is thatpossible? If not it won't be of much use.How do you handle internationalization?>StatusManager.push("Connecting to database");>try { ... } finally { StatusManager.pop(); }Could you make a push that takes an error handling strategyso that the try and pop are handled by push if desired?This would be much simpler.

As I understand article is not about status bar, but there is no problems to use
some key as attribute parameter for i18n "@Status("connecting_to_database")" and "ResourceBundle", current locale can be stored as thread local variable.
There is no problems with method parameters, you can use parameters in instrumented code too.

BTW It is possible to implement this stuff with plain reflection without any "magic". There a lot of examples on inet.