[JSR308] Re: Classfile representation of annotations

[Eugene Kuleshov]

Neal Gafter wrote:
> Both compile-time verification (of annotations) and annotations as 
> part of the interface don't require annotations be preserved in the 
> bytecode.  
  Neal, those are not the only use cases we are dealing with. Annotating 
implementation does open new possibilities for advanced analysis and 
declarative programming. Doug Lea also gave a good example of such 
application.
> By bytecode here I don't mean class files, but the part of the class 
> file representing the body of a method.  In other words, section 4 
> cites use cases that support changes to the class file format, but 
> don't support anything in the class file format to represent anything 
> in the interior of methods.
  Are you suggesting that developer should extract code that would 
requite special metadata for analysis or post processing into a separate 
methods or classes?

  Even if we will ignore suggested examples of the worst execution time 
analysis and other applications, such approach probably going to work 
for the statically bounded code, including the closures. But it is far 
from great if decisions need to be made at the execution time. So, we 
are facing a hard coding ahead of time, when developer is forced to 
characterize his code based on some assumptions or results of profiling 
vs. more lightweight declarative approach for allowing jut-in-time 
decisions.

  regards,
  Eugene


> On 2/3/07, *Michael Ernst* <mernst at csail.mit.edu 
> <mailto:mernst at csail.mit.edu>> wrote:
>
>     Neal-
>
>     > What API changes do
>     > we want that would require class file format changes?
>
>     I'm not sure there are API changes, but there are tasks that require a
>     classfile representation of the annotations.
>
>     Section 4 of the proposal starts out as follows:
>
>       4  Class File Format Extensions
>
>       Java annotations (including the extended annotations) must be
>     stored in
>       the class file for two reasons. First, they may be part of the
>     interface
>       of a class and, if so, must be available to the compiler
>     (really, to the
>       type-checking plug-in [Dar06]) when compiling clients of the
>       class. Second, since class files may originate from any source, the
>       information may be useful in other contexts, such as compile-time
>       verification.
>
>     Several examples have been posted to this list, as well.
>
>                         -Mike
>