JSR 250 (Common Annotations) approved: Why?

Just these days, JSR 250 has been approved in the public review ballot. Only IBM voted with "no".

I cannot understand the process entirely. Here are my reasons (also see my former entries JSR 250 (Common Annotations): Opinion and Is JSR 250 already mature?)

Some weeks ago, exactly on 2005-06-25, I send several pages of suggestions to jsr-250-comments@jcp.org (the mail given to do so). No answer, nothing. On 2005.07-21, I asked the spec. leader, Rajiv Mordani, at rajiv.mordani@sun.com to give me an explanation, why there is no answer to a well-meant, reasonable suggestion and contribution to JSR 250. Again, no answer, nothing. This is very frustrating for someone who spent several hours thinking and writing something to enhance the JSR 250 in its current form. I regard the JSR 250 as weak, premature and not acceptable in common. The comment of IBM gives at least *some* hint about the validity of my opinion.
Also, the concrete suggestions stated by individuals in a discussion about the first draft were not recognized and/or not considered.

I await the effect of the JSR to the community eagerly. Will the community accept and use the common annotations? I don't think so. But let's wait...

A frustrated blogger and neutralized JSR participant...

Physics and Computer Science

As I discussed in a former entry, Why Quantum Theory is important for Object Orientation, I see a connection, a conceptual link between physics and computer science.

That I am not alone with this opinion, although it might sound strange at first, could be seen by the article of Günther Meinhold: Einstein 2005: Modell und Wirklichkeit (model and reality), unfortunately for all non-German speaking people in a foreign language ;-)

The author draws the following comparisons, which I might be allowed to translate for showing the main idea behind the article:

Physics	Computer Science
Models of real objects	Models of the software product to develop
Models demonstrate how Nature works	Models show how the future software product works
Physical model	Logical object model
Mathematical model	Design object model
Mathematical calculation	Creation/Development of source code
Mathematical results for measurable physical parameters	Executable source code with testable functionality
Experiments and observations as test basis for the models and their results	Test of the functionality of the software against the product requirements

Yeahhh! I am not the only one out there believing in physics influencing computer science.

Anyone out there who doesn't love Einstein? Can't think so (he is not the father of the atom bomb, btw., please don't argue this way).

Is JSR 250 already mature?

As discussed earlier in a more general manner, I have the feeling that JSR 250 is away from a publishable form. Here are some of my concrete suggestions on how to pimp up the current paper released on June, 21st. I already sent them to the JSR commission as an RTF-document containing of several pages:

1. Define what the JSR 250 really is about. There is no commen consensus about which aspects should be covered by the common annotations to be defined in JSR 250.
2. I suggest including only annotations that have a generic character and support concerns of common interest that are not too complex (if they were they could be part of a separate JSR).
3. Group annotations: It should be quite obvious how to group the currently defined annotations in the public review paper. This should be a first and easy step getting a better feeling on where the journey goes.
4. Context-free aspects that could be covered by annotations could be:

• Design Patterns, especially the topics
• name of the pattern
• role within a design pattern
• description of the pattern itself and of its roles
• Design by Contract-related issues
• Architectural layers, such as (just to give an idea)
• persistence
• persistence mapping
• interfaces to third-party systems
• business logic
• domain logic
• transportation / protocols
• view mapping
• view logic
• display

The current version of the JSR 250 public review seems not adequate for manifesting or extending it in a way that it is displaying when reading it. As I suggested, there should be a general refurbishment of the whole paper. We are far from looking at if a single annotation proposed by the JSR’s expert group is useful, should contain additional information or should be renamed.

The problem is of more principle nature: The goal should be defined in round terms, a firm stand should be taken, context-free (or, say, generic) annotations should be considered instead of special ones and the direct support for J2EE specifics should be reconsidered.

Interesting resources:

• Discussion about the first draft

JSR 250 (Common Annotations): Opinion

The public review of the JSR 250 (Common Annotations for the Java Platform) has been published on June, 21st. After looking thru the list of annotations provided, I felt somewhat puzzled. IMHO, there is no clear line visible, no clear concept recognizable on which the selection of the annotation proposals is based.
I will write another entry soon explaining in more detail what I have written to the JSR 250 expert group as my proposal on how the annotations of this JSR should be choosen.

From my point of view, this JSR should mostly (exclusively?) contain annotations that are of common interest and are context free. One could joke about whether annotations specifically designed for J2EE could ever be of common interest. At least they are not context free.

Context free means in this context (intentional word repetition :-) ) that the thing annotated is context free. Take Design Patterns for example. They provide a context free concept of how to improve the architecture of your software system to allow for easier maintenance and better documentation of it.

Naming conventions for variables

After several years of experience in software development, I found a way of naming variables (attributes, fields, field declarations, as you like) that I feel convenient with.

First of all, in any class representing a business object (i.e., that contains business logic to a certain amount) there should only be private variables. Protected variables don't allow for implementing the Observer pattern! Use getters and setters instead. In few classes it may seem suitable using public fields because those classes are only used as very simple data containers.

My naming conventions for variables have evolved to the following:

• At class level - for private and protected fields (if any) - I use the prefix m_
• At method level there are two cases:
  a) method signature: I use prefix a_
  b) method body: No prefix, just the variable name.

Using this kit of simple concepts, it is very easy determining the scope of a variable just by looking at its name very superficially. In a setter method, the naming conventions allows to quickly find assignment errors and helps avoiding "this.", which in most cases (I saw) is regarded as ugly.

After an possible prefix the name of the variable starts with a lowercase letter. If there are multiple words concatenated together, from the second word on each word starts with an uppercase letter, such as: private int m_thisIsMyVariable;

Variables being constants by having the final static modifiers, are written all in uppercase letters. By the way, they are always public (at least if they are declared at class level).