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?
-
JSR 250: Common Annotations, What should it cover? (26 messages)
- Posted by: Dion Almaer
- Posted on: September 13 2004 22:54 EDT
Threaded Messages (26)
- no uber group by Bill Burke on September 14 2004 03:25 EDT
- no uber group by Rod Johnson on September 14 2004 04:29 EDT
-
no uber group by Corby Page on September 14 2004 09:27 EDT
-
no uber group by Rod Johnson on September 14 2004 09:37 EDT
- no uber group by Bill Burke on September 14 2004 11:35 EDT
-
no uber group by Rod Johnson on September 14 2004 09:37 EDT
-
no uber group by Bill Burke on September 14 2004 11:26 EDT
-
no uber group by Rod Johnson on September 14 2004 11:31 EDT
-
no uber group by Bill Burke on September 14 2004 11:44 EDT
- no uber group by Rod Johnson on September 14 2004 11:51 EDT
-
no uber group by Bill Burke on September 14 2004 11:44 EDT
-
no uber group by Rod Johnson on September 14 2004 11:31 EDT
-
no uber group by Corby Page on September 14 2004 09:27 EDT
- Belongs in appropriate jsr's by Thomas Roka-Aardal on September 14 2004 06:04 EDT
- Belongs in appropriate jsr's by Henrique Steckelberg on September 14 2004 08:33 EDT
-
Belongs in appropriate jsr's (or do they?) by Arik Kfir on September 14 2004 08:39 EDT
- Overlapping or not by Thomas Roka-Aardal on September 14 2004 10:38 EDT
- no uber group by Brian Miller on September 14 2004 14:21 EDT
- Meta-Annotations for String members of Annotations by Christian Essl on September 15 2004 23:21 EDT
- Meta-Annotations for String members of Annotations by Brian Miller on September 16 2004 10:57 EDT
- no uber group by Rod Johnson on September 14 2004 04:29 EDT
- JSR 250: Common Annotations, What should it cover? by Rod Johnson on September 14 2004 06:02 EDT
- invariant expressions by glauco scheffel on September 14 2004 08:42 EDT
- invariant expressions by Brian Miller on September 16 2004 11:21 EDT
- JSR 250: Common Annotations, What should it cover? by Carlo Marchiori on September 14 2004 12:01 EDT
- JSR 250: Common Annotations, What should it cover? by Carlo Marchiori on September 14 2004 12:03 EDT
- JSR 250: Common Annotations, What should it cover? by Juozas Baliuka on September 14 2004 13:03 EDT
- version and version requirements by Tom Eugelink on September 17 2004 03:00 EDT
- Version and version dependencies by glauco scheffel on September 17 2004 16:03 EDT
- Classified annotations by Jeff Zhuk on January 18 2005 01:28 EST
- Feedback and comments not considered?! by Klaus Meffert on July 30 2005 08:35 EDT
-
no uber group[ Go to top ]
- Posted by: Bill Burke
- Posted on: September 14 2004 03:25 EDT
- in response to Dion Almaer
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 -
no uber group[ Go to top ]
- Posted by: Rod Johnson
- Posted on: September 14 2004 04:29 EDT
- in response to Bill Burke
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. -
no uber group[ Go to top ]
- Posted by: Corby Page
- Posted on: September 14 2004 09:27 EDT
- in response to Rod Johnson
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. -
no uber group[ Go to top ]
- Posted by: Rod Johnson
- Posted on: September 14 2004 09:37 EDT
- in response to Corby Page
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 -
no uber group[ Go to top ]
- Posted by: Bill Burke
- Posted on: September 14 2004 11:35 EDT
- in response to Rod Johnson
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. -
no uber group[ Go to top ]
- Posted by: Bill Burke
- Posted on: September 14 2004 11:26 EDT
- in response to Rod Johnson
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 -
no uber group[ Go to top ]
- Posted by: Rod Johnson
- Posted on: September 14 2004 11:31 EDT
- in response to Bill Burke
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 -
no uber group[ Go to top ]
- Posted by: Bill Burke
- Posted on: September 14 2004 11:44 EDT
- in response to Rod Johnson
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 -
no uber group[ Go to top ]
- Posted by: Rod Johnson
- Posted on: September 14 2004 11:51 EDT
- in response to Bill Burke
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. -
Belongs in appropriate jsr's[ Go to top ]
- Posted by: Thomas Roka-Aardal
- Posted on: September 14 2004 06:04 EDT
- in response to Bill Burke
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. -
Belongs in appropriate jsr's[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: September 14 2004 08:33 EDT
- in response to Thomas Roka-Aardal
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 -
Belongs in appropriate jsr's (or do they?)[ Go to top ]
- Posted by: Arik Kfir
- Posted on: September 14 2004 08:39 EDT
- in response to Thomas Roka-Aardal
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. -
Overlapping or not[ Go to top ]
- Posted by: Thomas Roka-Aardal
- Posted on: September 14 2004 10:38 EDT
- in response to Arik Kfir
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? -
no uber group[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 14 2004 14:21 EDT
- in response to Bill Burke
I do not agree with the formation of this JSR.
JSR-250 is J3EE. What have you got against J3EE? -
Meta-Annotations for String members of Annotations[ Go to top ]
- Posted by: Christian Essl
- Posted on: September 15 2004 23:21 EDT
- in response to Bill Burke
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 ;). -
Meta-Annotations for String members of Annotations[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 16 2004 10:57 EDT
- in response to Christian Essl
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. -
JSR 250: Common Annotations, What should it cover?[ Go to top ]
- Posted by: Rod Johnson
- Posted on: September 14 2004 06:02 EDT
- in response to Dion Almaer
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 -
invariant expressions[ Go to top ]
- Posted by: glauco scheffel
- Posted on: September 14 2004 08:42 EDT
- in response to Dion Almaer
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 -
invariant expressions[ Go to top ]
- Posted by: Brian Miller
- Posted on: September 16 2004 11:21 EDT
- in response to glauco scheffel
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. -
JSR 250: Common Annotations, What should it cover?[ Go to top ]
- Posted by: Carlo Marchiori
- Posted on: September 14 2004 12:01 EDT
- in response to Dion Almaer
In java there should not exist any library of name common*.jar. -
JSR 250: Common Annotations, What should it cover?[ Go to top ]
- Posted by: Carlo Marchiori
- Posted on: September 14 2004 12:03 EDT
- in response to Dion Almaer
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. -
JSR 250: Common Annotations, What should it cover?[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: September 14 2004 13:03 EDT
- in response to Dion Almaer
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. -
version and version requirements[ Go to top ]
- Posted by: Tom Eugelink
- Posted on: September 17 2004 03:00 EDT
- in response to Dion Almaer
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". -
Version and version dependencies[ Go to top ]
- Posted by: glauco scheffel
- Posted on: September 17 2004 16:03 EDT
- in response to Dion Almaer
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[ Go to top ]
- Posted by: Jeff Zhuk
- Posted on: January 18 2005 01:28 EST
- in response to Dion Almaer
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. -
Feedback and comments not considered?![ Go to top ]
- Posted by: Klaus Meffert
- Posted on: July 30 2005 08:35 EDT
- in response to Dion Almaer
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?