[JSR308] Proposal: Multiple Instance of same Annotation, Annotation Inheritance

Maxim Kizub mkizub at gmail.com
Fri Oct 3 10:33:11 EDT 2008

Hello Niko,

I agree with most of your proposals related to annotation inheritance, except

2008/10/3 Niko Matsakis <niko at alum.mit.edu>:
> 2. Subtyping among annotations
> ...
> To avoid complications, only single inheritance would be permitted.

Look, the current definition of annotations was also keeped simpler,
to avoid complications.
And now you propose to extend it, because you lack some features.
In the future, someone else will need multiple inheritance (for a very
good reason), and will ask to
extend annotations again - the java will be changed again.
There should be very good reasons to avoid multiple inheritance for annotations.
I see none of them.
Annotations are interfaces (by implementation) - so there will be no
problem from implementation
point of view.
You already want to overwrite super-fields. So, in case of conflicting
super-fields, we may
ask the programmer to overwrite the conflicting fields explicitly.

I'd like also add a proposition to have optional or nullable fields in
With extended capabilities of annotations, there will often be a situation, when
the annotation have too many fields (with little significant), and the
.class files
will become too big.
Optional fields will be skipped from .class file, if their value is
not explicitly specified,
and their value will be taken from the annotation declaration (default value).
Nullable fields will be able to take 'null', instead of definite
value. First, this will be useful
if the field's type is another annotation type with rather big content
size. Second,
it's sometime convinient to specify the value 'none/void/null/unit',
instead of any
existing (even empty) value.
Such fields may need to be explicitly marked as @Optional and @Nullable
both for safness and backward compatibility.

  Maxim Kizub

More information about the JSR308 mailing list