JSR 250 has just released its first draft as you may have seen. JSR 250 tries and standardize the set of common annotations that will used across the EE environment. Jboss is part of this expert spec committee. For those of you that have been sleeping under an xdoclet rock for the past 2 years annotations are truly powerful constructs when it comes to EE.

It turns out that *simplicity* with declarative java programming models was the true message of AO, not complexity. Finally we were able to simplify the programming model of EE while preserving the power of the services of EE. What is there not to like? No wonder EJB3 is the cat's meow. Application development is getting simplified fast.

JSR 250 is significant in that it strives to standardize the tag definitions across JSR's when it comes to EE behavior. It is a valid goal, a goal of "glue" a very AO goal. For example it standardize declarative annotations for security. Great idea, it is used across a variety of JSR's, each defines its model and framework that unify this are today proprietary models. The new programming model of java+metadata needs standards. Java5 lead the way thanks to Josh Bloch (what a contribution!) and EE is following the lead. EJB3 is, again, a great example of this type of simplification of the standards, it is standardizing about 7 pojo services incluing remoting, DI, persistence, transactions, security, lifecycle and interception.

But I have a beef with JSR250. The problem as I see it is that Annotations are usually the result of expert domain input. For example, standardizing the persistence tags alone is no trivial task. That effort is very expert intensive. In other words it is my belief that the tag definition belongs to the individual EG and JSR's. It should however be a requirement, probably enforced by JSR250, that all new JSR's focus on ease of use by providing java+metadata programming models, the equivalent of a driver for the operating system crowd, this way the stuff is easily usable out of the gates.

In order for this to work we would need JSR250 to be an expert at EVERYTHING. Well the good news is that Gavin sits on JSR250, so there is hope :). But basically as it stands JSR250 tries and define programming models that could potentially encroach on the work of individual JSR's.

There is a very valid role for JSR250 that hasn't been articulated to the best of my knowledge. It could expand its monitoring of the various groups for cross-cutting aspects, essentially it could be an AO watchdog for EE. This way the whistle blowers could call an aspect when they see one, and they can trigger "cross cutting standardization" across the specs and define that standard programming model. I will go on record *once again* saying that I believe this is the future of the EE specs, a series of standalone aspects standardizaed for the whole java platform, for example message driven pojos are a very valid construct we have had in JBoss for 1 year but that feature may not make the first cut of EJB3 due to the load of work. Well if we split it up it becomes manageable. Maybe something for EJB4 :)

In short JSR250 is a GREAT attempt at this new simplified, Java based programming model and its potential is huge but I do believe we rushed a little bit into forming this JSR and its scope is still ill defined in my nsh opinion. It is well intended and acknowledges that the programming model should be simplified through annotations but its scope must be clarified.

marcf