[JSR308] Can we agree on our goals? (Google comment on the review ballot)

[Neal Gafter]

I worked with Joshua Bloch to craft that response. And I'd like to express
the concern that led JSR175 not to record local variable annotations in the
class file: the structure of the bytecode in the class file does not
correspond in any reliable way to the structure of the source code. For such
annotations in the class file to be useful to more than a few tools, more
information about the structure of the program is required. Saying that it
is "good enough" for one or another specific purpose would result in a
specification that is only "good enough" for one or two purposes over the
next few years, and then the whole thing will want an overhaul as new use
cases arise. That would be a waste of our time.

If recording the annotations (on local variables, for example) in the class
file is desireable, then the structure of the bytecode should be revised to
enforce a 1-to-1 mapping from source code. One way to achieve that is to
record a (possibly desugared) parse tree instead of the sequence of
instructions. In other words, overhaul the bytecode specification. Simple
languages like lisp and smalltalk are ideally suited to this approach, and
Java's complexity gets in the way, but the bytecode-instruction-range
apprach has severe limitations that will just get in the way of making much
sense of the data in the byte code.

I said it in private mail to a couple of participants, and I'll say it
again: to determine how the data is to be represented in the class file, we
should start with the modifications we want to the reflection, mirror, or
other APIs where this data is to be made available. Possibly we should build
off the com.sun.source.tree APIs, which are used to represent the structure
of the whole program (including statements and types) and are available
inside the annotation processor.  In other words, we should keep our heads
out of the bytecode gutter, because it is in the platform's best interest
that we avoid making it more brittile.

For the source code (language) changes, we should identify which
semantically meaningful nonterminals we want to support annotations on, and
specify them by modifying the grammar. We should also remain aware that,
given the structure of the Java language, we will likely require a distinct
solution for every such nonterminal. That means that our "solution" will
appear to be (and will actually be) a collection of distinct and unrelated
hacks for different language constructs, having only in common that they
specify annotations using the @ syntax. The final result will not be any
better than a result from the incremental approach (which has been
characterized as an ongoing stream of feature requests, which at least has
the advantage that we'll only get into the language the things we find are
actually needed).

Finally, I should note that the Google vote was a strong endorsement of
supporting additional source annotation locations, but only cautious support
for exploring the possibility of recording them in the class file.

On 2/2/07, Eugene Kuleshov <eu at javatx.org> wrote:
>
>
>   We already seen Googlers in this mailing list. I wonder if they or the
> one responsible for the review ballot comment can give more insight and
> perhaps some practical use cases that drove their comment.
>
>   regards,
>   Eugene
>
> PS: here is the comment:
>
> On 2006-10-30 Google Inc. voted Yes with the following comment:
> This note confirms our understanding that Section 2.1 should be less
> specific. It should state the problem, which is that current
> restrictions on the placement of annotations limit their utility for
> certain applications such as program verification. Section 2.1 should
> outline the proposed solution: that annotations should be permitted to
> appear in more places, and perhaps local variable annotations should be
> allowed in the class file. (We say "perhaps" because the JSR-175 EG
> recognized that there are difficulties associated with this.) The
> specific syntax and semantics should be left up to the expert group. The
> syntax and semantics currently shown in Section 2 (and in Michael
> Ernst's paper) belongs in Section 3, where it can serve as a key
> contribution without constraining the expert group.
>
> With this understanding, Google casts an enthusiastic yes vote, and
> looks forward to serving on the Expert Group.
>
>
> Trevor Harmon wrote:
> > Google's comment was, "Annotations should be permitted to appear in
> > more places, and perhaps local variable annotations should be allowed
> > in the class file."
> >
> > Note that Google says "more places" not "local variables". The
> > "perhaps local variables" remark was just to remind folks that if
> > local variables are to fall under that "more places" umbrella, then
> > the class file format will have to be changed.
> >
> > If Google's definition of "more places" includes loops and blocks --
> > and I think that's a safe assumption -- then all three comments are in
> > agreement.
>
>
> _______________________________________________
> JSR308 mailing list
> JSR308 at lists.csail.mit.edu
> https://lists.csail.mit.edu/mailman/listinfo/jsr308
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/pipermail/jsr308/attachments/20070203/a90991a2/attachment.htm