Annotations for language features

[Adam Malter]

On Sun, Aug 16, 2009 at 2:23 PM, Artur Biesiadowski<abies at adres.pl> wrote:
> 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
>
>

I think anybody who's worked with 'code generating' annotation
processors could enumerate a number of good reasons to stay away.

They have been universally fragile, difficult to test, difficult to
code and difficult to debug. Additionally, they place a serious
complexity and runtime strain on development tools. The 'code' must be
generated realtime in order to preserve 'as your type' error hints
(aka, insure an accurate AST model with references back to true source
code).  Additionally, they introduce dependency graphs that are not
clearly resolved even by the current generation of annotation parsers
(See Joe Darcy's attempt to build a *third* Apt API in as many
versions of Java and then lookup the concept of generation rounds in
the Eclipse apt development documentation)

All those nice Eclipse/Idea/Netbeans features like dynamic method
lookup, error highlighting, templating, etc, must run the annotation
processors/plugins on the entire codebase as you go. This works fine
for smaller codebases, but as projects get larger, the pressure to
keep the dynamically generated code in sync with refactors and back
merges and et. al, gets harder and harder.

Also, the hurdle for building a Java IDE with these basic features is raised.

I believe that tools like Project Lombok are useful for illustrating
new paths the language can take, but I'd be hesitant to integrate any
library using it into any production project.

While the class files for the library may be 'JVM' compatible, without
the exact version of the plugin, the source files might as well be
Groovy or Scala (aka, opaque to the java developer) - I know this
hyperbole, we are only talking about getters/setters, but the slippery
slope argument is no fallacy if you've ever used DTO annotation
processors for the major enterprise stacks. Generated code is a useful
trick up the language's sleeve to help make very complex tasks
automated, but it's use in the base classpath should be discouraged if
not forbidden.

As an alternative, if what the @Property annotation did was both
create the getters/setters in the original source, validated them if
they were already present, and served as a hint to aware IDE's (which
would then hide the boiler plate), I'd be on board 100%.

The line between hinting and validation vs opaque creation is wide and
the downsides make it not worth crossing.

IMHO of course :)

-adam malter @ tradecard