The new JSR 250: Common Annotations for Java, is out and about. The idea of standardizing common annotations so we don't get duplicates is a good one, but what is the scope of this JSR? What annotations should be here, versus in their own specifications?

I do have a concern that we will have a group making decisions that should be deferred. Again, this group could be an unbrella group for others which come up with more specialised topics... which yet shouldn't be in their own specs.

For example, OR mapping can be shared between JDO and EJB (although I would prefer that there was ONE transparent persistence spec... but I won't go there ;).

In this case, it may be better to to see a small spec/group formed for this purpose.

What would you like to see covered?

I do not agree with the formation of this JSR. It smells way too political for may tastes. At most it should only research all JSRs to make sure there is not overlap on annotation functionality and get the appropriate specs to collaborate. This group should not formalize anything.

Bill

From the JSR-250 page:

This JSR will develop annotations for common semantic concepts in the J2SE and J2EE platforms that apply across a variety of individual technologies. With the addition of JSR 175 (A Metadata Facility for the JavaTM Programming Language) in the Java platform we envision that various JSRs will use annotations to enable a declarative style of programming. It would be unfortunate if these JSRs each independently defined their own annotations for common concepts. It would be especially valuable to have consistency within the J2EE 5.0 component JSRs, but it will also be valuable to allow consistency between J2EE and J2SE. It is the intention of this JSR to define a small set of common annotations that will be available for use within other JSRs. It is hoped that this will help to avoid unnecessary redundancy or duplication between annotations defined in different JSRs. The exact set of annotations will be developed in consultation with the various specifications leads who are currently planning to use annotations within their JSRs.

Exactly which part of this do you disagree with? Or is it just that you want as many classes as possible to be forced to depend on ejb.jar (or any J2EE JAR for that matter)?

JSR-250 seems an obvious and important way to try to manage the impact of annotations on the whole Java platform. I don't think it's "political"; I think it's technically the right thing to do.

Exactly which part of this do you disagree with? Or is it just that you want as many classes as possible to be forced to depend on ejb.jar (or any J2EE JAR for that matter)?

You're smarter than that, Rod. Looking at Bill's notes from two days ago, it's hard to make the case that Bill is against annotations, or that he wants forced dependencies on the J2EE classes.

In fact, I am much more worried about these dependencies being introduced from a shadowy JSR group with unnamed employees from BEA and Sun. I would like to see this group conduct itself with the same openness and community involvement as the EJB 3.0 group. The EJB 3.0 group may be no less political, but I am not as worried about that group ambushing us with short-sighted standards.

Looking at Bill's notes from two days ago, it's hard to make the case that Bill is against annotations, or that he wants forced dependencies on the J2EE classes.

I didn't say that Bill was against annotations: I know he favours them... The blog reference doesn't look relevant to JSR-250 or any other JCP effort--it's about JBoss AOP.

As for "shadowy group", the community should take an interest in JSR-250 to try to get it right. The JSR-250 spec group is still open. I believe the alternative--a mess of incompatible annotations defined in different specs--would be a lot worse. Some core concepts like persistence and transaction management will span multiple JSRs and implementations. Fragmentation is in nobody's interests.

Rgds
Rod

like persistence and transaction management will span multiple JSRs and implementations. Fragmentation is in nobody's interests. RgdsRod

Its pretty obvious what your real agenda here is Rod.

Exactly which part of this do you disagree with? Or is it just that you want as many classes as possible to be forced to depend on ejb.jar (or any J2EE JAR for that matter)? JSR-250 seems an obvious and important way to try to manage the impact of annotations on the whole Java platform. I don't think it's "political"; I think it's technically the right thing to do.

An Annotation is an API. An uber group should not be deciding J2EE apis. J2EE should be. EJB, JCA, etc... already have an uber group in the J2EE 1.5 JSR, they don't need another.

Unfortunately, I think without a clear mandate or direction, this JSR is doomed to politics. Those whose ideas were outnumbered in the sub committees will have yet another uber group to whine to.

Now, if the group had specific goals like defining an annotation overriding facility (which, BTW, I proposed twice to the JSR 175 mail list and was shot down), the JSR could be a bit more focused and the center for political.

Bill

An Annotation is an API.

Yes.

An uber group should not be deciding J2EE apis. J2EE should be. EJB, JCA, etc... already have an uber group in the J2EE 1.5 JSR, they don't need another.

Part of the point of JSR-250 is to separate some things which should be separate from J2EE APIs and make them available to J2SE also.

Now, if the group had specific goals like defining an annotation overriding facility (which, BTW, I proposed twice to the JSR 175 mail list and was shot down), the JSR could be a bit more focused and the center for political.

That's an excellent idea, obviously necessary, and hopefully they may take some interest in it...

Rgds
Rod

Part of the point of JSR-250 is to separate some things which should be separate from J2EE APIs and make them available to J2SE also.

It should be the other way around. The individual specs should be defining these APIs. Otherwise you have a JSR that is defining APIs for the entire JCP. Without clear direction and goals, this JSR could turn into a committee deciding every API of every JSR. You're already talking about doing this for persistence when persistence experts should deciding these APIs.

Bill

Without clear direction and goals, this JSR could turn into a committee deciding every API of every JSR. You're already talking about doing this for persistence when persistence experts should deciding these APIs.

"Without clear direction and goals," any JSR will turn into a mess. The JSR-250 page, which I quoted above, stresses consultation with spec leads of other JSRs.

I completely agree with Bill. If there should be a standardized way of annotating "something", then that annotation belongs with the "something" jsr. Simple as that.

I completely agree with Bill. If there should be a standardized way of annotating "something", then that annotation belongs with the "something" jsr. Simple as that.

The problem is that there are more than one "something" doing the same thing out there. Take JDO and EJB for example, both define persistence mechanisms, and both should follow one annotation standard only instead of 1 different and specific for each, generating even more fragmentation. That's the last thing we need now.

Regards,
Henrique Steckelberg

But what if more than one JSR needs the same annotation? I'm sure there's *some* overlaping between JSRs, as many of them interact with one another.

That said, I agree that when regarding to annotations specific to a certain JSR's area, those annotation belong in that JSR - no doubt there.

I guess the question of overlapping really moves us toward the issue on "conceptual" versus "actual". JDO versus CMP is one of those, but noone would consider them equal on anything but a conceptual level, and they would most likely require quite different attributes. If we introduced common annotations for conceptually equal aspects, wouldn't it get really messy if they couldn't be used in place of the other anyway? It would also require a high-enough-level of abstraction for attributes which basically reduces everything to the least common denominator?

I do not agree with the formation of this JSR.

JSR-250 is J3EE. What have you got against J3EE?

I'd like the group to define a set of meta-anotations which mark the String values of annotations to be of a certain pattern or general useful type. Ie. Meta-annotations which define a String member as beeing a Date, a (wildcarded) method-name, a tabel-name or other general useful concept. Maybe also a general regex meta-annotation. I think this would help IDEs and me ;).

I'd like the group to define a set of meta-anotations which mark the String values of annotations to be of a certain pattern or general useful type. Ie. Meta-annotations which define a String member as beeing a Date, a (wildcarded) method-name, a tabel-name or other general useful concept. Maybe also a general regex meta-annotation. I think this would help IDEs and me ;).

An annotation whose value is XML can be validated by XML Schema. I wonder if this is being considered.

What would you like to see covered?

To start with:
- transaction annotations: not technology specific, but common conceptual information such as propagation and isolation level
- persistence: identify classes and fields or methods as persistent. Again, at a conceptual level--I believe it's going backwards to bake table and column names into classes

So long as implementation specifics are kept out, as they should be, I don't believe it would take very long to define a good set of annotations, and application developers will benefit from potential interoperability between different environments. It would be good to have a quick 1.0 release addressing the low-hanging fruit, so as not to delay other specs which would need to use it, followed by a 2.0 release addressing a wider range of issues.

Rgds
Rod

We can extend the language to include invariant expressions for classes and modules, and pre- and post-condition expressions for functions and methods. With this Java will support 'Design by Contract', beyond "a simple assertion facility" look at: http://developer.java.sun.com/developer/bugParade/bugs/4449383.html

So how many of these can gather under JSR-250's umbrella? JSR-250 is supposed to aim for basic reusable parts, but that's still a huge pile of concepts.

- Annotations for invariants and conditions.

- Annotations for multiple implementation inheritance, aka "mixins".

- Asynchronous invocation annotations for fire-and-forget, queueing, etc.

- Gang-of-Four design pattern annotations.

- UML annotations.

- JAXB annotations.

- Aspect annotations.

In java there should not exist any library of name common*.jar.

Any jsr should design its own annotations. If there are some in common with other jsrs, a new jsr should be forked to design those topic specific annotations.

It must be a good idea to have ubergroup and jar file for all checked exeptions too, It will be very cool and easy to use.

One of the biggeste advantages that DotNet has over Java IMHO, is that the assemblies support versions and version requirements; it is possible to specify that a certain assembly (jar) requires another assembly to have at least or exactly a version. The classloader then makes sure that classes from that assembly only access the appropriate other classes. In theory (I have so far never tried this in real life) this makes it possible to write applications that use to incompatible versions of the same library.

Unfortunately Java allows for writing custom classloaders, so there is a big hurdle there, but I think the basic idea is great. And it must start somewhere.

So my suggestion is to use annotations for class version and class version requirements in order to, in the long run, get rid of the "JAR hell".

We can simplify de adoption of Java™ Product Versioning

http://java.sun.com/j2se/1.4.2/docs/guide/versioning/spec/versioning2.html#wp90779
http://www.javaworld.com/javaworld/jw-09-2002/jw-0920-jpvs.html

Classified annotations would describe a business area and purpose of Java classes to enable a mechanism capable of accepting, classifying, and providing meaningful information about new software.

This would be more open than javadoc comments. Javadoc API can stay internal while classified annotations may be directed to specialized yellow pages.

And this is different from the web services that represent a small fraction of software.

The purpose is to capture and make available (when developer/owner wants it) general search information that can decrease replication efforts and increase possibilities for collaboration.

The response to this thread shows the common interest of the JSR. Several good suggestions were made. Over a month ago, I sent my quite long comments to the JSR 250 mail address (jsr-250-comments at jcp dot org). After not hearing anything, I decided to ask the spec. leader (rajiv dot mordani at sun dot com) if it is possible getting feedback and what will happened with the feedback received in general.

When taking a look at the current specification you could easily find out that the more serious suggestions have not been considered at all. Additionally, I find the spec. in its current form unacceptable: the goals are very generic and it is not clear to any extend what should be covered by "command annotations" resp. what "common" means. Following this, the annotations described have no closer common context (and if, it is not recognizable by reading the paper itself).

This sort of reduces my trust in JSR's in general and my fear about the "effectiveness" of the process is increased when looking at the long list of expert group members. Why have so many members when there is not the outcome the community would want to see? If my observations are wrong, then, please, could the responsible persons of JSR 250 answer to user's feedback adequately?

What are your experiences?