[JSR308] Why do annotations only allow limited set of attribute types?

[David Goodenough]

On Thursday 25 September 2008, Michael Ernst wrote:
> David-
>
> (This is an off-list response.)
>
> > The set of types allowed for attributes of annotations is very limited. 
> > Why?
> >
> > I have a need for more generic attributes, which I can detail if needed,
> > and this looks like an arbitrary and pointless restriction.
>
> I appreciate your feedback and questions, which are very useful.
>
> I have a small suggestion regarding the phrasing of questions.  I hope I am
> not out of place in making it, and I've made similar suggestions to other
> people.
>
> Please try to write your messages so as to assume that there is a good
> reason.  Often, there really is a good reason, or at least not a stupid
> one!  Then, ask what that reason is, rather than using words that come
> across strongly like "arbitrary and pointless".  Such words tend to
> antagonize, and antagonized people are less likely to give you the
> information you are seeking.  The words also make it seem that you have an
> agenda rather than being most interested in the true design rationale.
>
> It always helps to give your concrete examples as well.
>
>
> Thanks again for your participation, and keep the questions coming!
>
>                     -Mike

I suppose it was the way in which the error message expressed itself, it
listed an apparently arbitrary list of things that were allowed, without 
making the point that what was really meant was that it had to be a 
constant.  Actually the message is misleading, saying that only certain
types are allowed, functions that return that type (say a String), which would 
be allowed in normal places that that required String (say a constructor
arguement) are not allowed, only constant strings and the error message
- at least the one that Eclipse produces - does not mention this.

I guess that at the root of my problem is that what I need are run time
annotations, not compile time ones.  And 308 is a move in the that 
direction from what I understand.  I never use APT (or its compiler 
equivalent), but I do use the presence of annotations at run time.

Unlike compile time ones, which obviously can only have compile time
values (i.e. program constants), run time ones are logically the same as
any other declaration, and declarations can contain expressions and values
so if annotations are being used in that context it makes sense that they
should also be allowed such expressions and values.  And of course 
annotations are marked with the context in which they are allowed so it 
should be possible to allow such expressions and values for annotations 
that are run time annotations - which would make them a whole lot more
useful.

My particular need comes from bean binding.  I do my bean binding in 
a novel way, in particular I do not use strings to identify the properties.
I don't do this because it is error prone, and the compiler/IDE can not
check that I get it right.  Having the compiler/IDE check it and tell me
when I am writing the code is one of the Joys of Java.

So I have derived a scheme which uses unique instance values to work out
properties (see http://dga.co.uk/blog ).  There will be more going there soon
as that was written when I only had a proof on concept, now I have converted
an entire application to use this and there are a few things that I had not
worked out with the proof of concept, and some implementation details that
I will be adding.  But that give the principle of the thing.

So I would like to be able to use this with annotations, but it requires 
declaration time expressions to work.  So for instance I have a static
method (path) which takes a class object and the value of a field from it
and produces a path string and another method (property) which returns
a BeansBinding Property object.  I can not use either of these.  I would 
like to be able to say (lets say the object is a Customer object and the
field I want is the customer Name):-

@Bind(path(customer, customer.getName())
private JTextField  field = new JTextField();

or:-

@Bind(property(customer, customer.getName())
private JTextField  field = new JTextField();

but neither of these compile.  The first would require a String value which is
legal so the annotation would compile, but when I come to use it, its not a 
compile time constant so it gets rejected, and the second would require the 
field type in the annotation to be Property (from the beanbinding package), 
and that is not legal so the annotation will not compile as it is not in the 
magic list and is also not a constant so again I could not use it even if the
annotation were legal.

But I think that this is a logical use of annotations and is not unique to my 
odd idea of having properties without strings.  I also think that the concept
that some annotations are never used by APT and could therefore be 
allowed "easier" rules is a useful one that could make annotations a whole
lot more useful than they already are (and I like them a lot).

David