Annotations for language features

Artur Biesiadowski abies at adres.pl
Sun Aug 16 11:23:18 PDT 2009


Reinier Zwitserloot wrote:
>
> Sure, no annotations in the core java libraries actually create 
> generated source files, but the ability to generate files clearly 
> isn't an afterthought; it's a very valuable part of the annotation system.
There is a difference between generating additional code from 
annotations (like many remote invocation wrappers do) and actually 
changing what the code containing the annotations does.

I think it is a matter of taste. For me the line is somewhere between 
having annotation

@NonNegative int x;

which gives annotation-aware compiler right to reject/warn on certain 
assignments, versus

@Unsigned int x;

which would mean that this int is treated as real unsigned integer on 
all comparisons/shifts/etc (maybe even using different set of bytecodes 
in future jvm). Same way, for me

@Property int x;

would be acceptable as a kind of marker for compiler which would reject 
source file if it doesn't contain properly constructed getters and 
setters, but not as something which silently generates missing methods.

You asked for the reasons and I must say that I'm in trouble to find any 
hard ones. I think that for me main thing is to avoid 'hackery' in 
language because of compatibility reasons only. There is considerable 
hackery in implementation already (private field/method accesors from 
inner classes, generics erasure) - but whatever you can say about 
generics, they got implemented as Map<String,Something> x; instead of 
@Map(String.class,Something.class) Map x; I feel that language 
extensions should be kept this way - even if it is costly in term on 
compiler support.

> > Next step and we will end up Borland 
> > Pascal way and put control instructions in comments/javadoc.
>
> That's a logical fallacy.
It might look like one, but I have already been through that when 
discussing Design By Contract support in java long time ago. Take a look at
http://www.mmsindia.com/DBCForJava.html
for example for a solution which takes this route. Today, with 
annotations, we probably won't actually end up back in javadoc code 
generation camp, but this was more a mindset rather than particular 
solution I was referring to.

With best regards,
Artur Biesiadowski



More information about the coin-dev mailing list