[JSR308] Can we agree on our goals?

[Gary T. Leavens]

Hi Ted and all,

About your note below, I feel comprelled to repeat my remarks about
Flon's axiom.  Of course you can write unreadable programs with our
annotation proposal.  You can write unreadable programs in Java
already and sure, we'll provide new ways to do that.  But that's not
the point.  The point is whether we'll help programmers use
annotations intelligently to accomplish what they want to do.  Most of
those good uses of annotations will be fairly spare.

The valid concern in your remarks is what happens when there are two
or more sets of annotations in use in one program: can programmers
produce something that is sensible?  I agree that using two or more
sets of annotations might make it difficult for programmers to write
code that is easy to read, but presumably tools like Eclipse could be
used to suppress one or more sets of annotations.  And note that this
concern is independent of where programmers can write annotations,
even in current Java this could already be a problem.  So I don't
think this is an argument we should worry about for JSR 308, even if
it's a more valid concern.

On Thu, 1 Feb 2007, Ted Neward wrote:

> 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
>
>
>
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>


         Gary T. Leavens
         Department of Computer Science, Iowa State University
         229 Atanasoff Hall, Ames, Iowa 50011-1041 USA
         http://www.cs.iastate.edu/~leavens  phone: +1-515-294-1580