[JSR308] Can we agree on our goals?

[Ted Neward]

There's also clearly a readability issue here. Annotations everywhere
means... annotations everywhere. Using two or three different sets of
annotations together in a single program could really quickly make
"annotation hell". We're assuming throughout this discussion in our examples
that only one set of annotations will be in play, but it doesn't take a lot
of imagination to come up with a couple of sets that could easily be used
simultaneously. Reducing the number of places an annotation can be applied
will (I hope) reduce the potential for unreadable code.

As an exercise, during the JSR 175 discussions I took a moment and wrote up
a class that put an annotation in every possible place an annotation could
go, and judged how it all looked when done. It was a bit cluttered, but
since annotations neatly fit into every place a modifier sat, it sort of
made sense and still seemed readable. I'd strongly suggest we do something
similar (formally or informally), just to make sure we get a clear view of
what we're creating.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: jsr308-bounces at lists.csail.mit.edu [mailto:jsr308-
> bounces at lists.csail.mit.edu] On Behalf Of Tom Ball
> Sent: Thursday, February 01, 2007 12:26 PM
> To: Eugene Kuleshov
> Cc: jsr308 at lists.csail.mit.edu
> Subject: Re: [JSR308] Can we agree on our goals?
> 
> Eugene Kuleshov wrote:
> > Gary T. Leavens wrote:
> >> For my part, I would be very happy with adding the ability to have
> >> annotations on types and statements (or even just loop statements).
> >> I'm not personally trying to use any kind of strategy to lead us down
> >> a slippery slope towards annotations on all possible syntactic
> >> categories.  I think if Java programmers can annotate declarations,
> >> types, and (loop) statements, that will be plenty.
> >  Gary, why limit it on loops and not all { } blocks?
> 
> At the risk of polluting this discussion with implementation details,
> javac block nodes have an internal modifiers field, and modifiers hold
> annotations.  The Compiler API only allows access to the static flag in
> those modifiers (BlockTree.isStatic()), but that interface can be
> extended in a backwards-compatible way to provide access to the
> annotations.
> 
> The advantage of allowing annotations on blocks rather than on
> statements is that developers can surround any statement with a block if
> they want to annotate it, without  having to make radical modifications
> to the compiler.  It should also make scoping issues simpler, too.  I
> haven't thought out what the impact of having block annotations will be
> on JVM classfiles, but suspect that the current proposed attribute will
> work.
> 
> Tom
> 
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date: 2/1/2007
> 2:28 PM
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.19/663 - Release Date: 2/1/2007
2:28 PM