[Jsr308-statements] First draft of proposal

[Eugene Kuleshov]

Trevor Harmon wrote:
>>  It doesn't seem to make sense sense to expose them trough runtime 
>> reflection API because statements and other method details aren't 
>> exposed at the runtime.
> You're saying that because statement annotations have no reflection 
> API at the present time, we should mark all statement annotations as 
> invisible. This is dangerous. There may be a future reflection API, or 
> perhaps some third-party API, that needs to consider run-time visible 
> statement annotations. To account for such future expansion, we should 
> be consistent and record the same visible/invisible distinction that 
> all other annotations do, even if the distinction is not being exposed 
> right now through an API.
>
> Besides, the whole visible/invisible thing is really quite trivial. We 
> can implement it now without any trouble. (My javac patch already does 
> this.) What do we have to gain by not supporting it?
  I don't really see what you can gain by supporting it.

  The bytecode-level analyzer or transformer can still read "invisible" 
annotations before classes are loaded. But then, once classes are 
loaded, JVM doesn't really allow to do much about the method code 
(except reload/redefine it, which effectively the same thing as 
transforming things before loading). So, it seems like it would be a 
redundant thing, unless method implementation details will be exposed 
trough reflection API. But then it is probably unlikely that it would be 
a bytecode-level exposure (i.e. it such reflection could return a Java 
AST representation) and so, it may not need those bytecode attributes 
anyway.

  Other then that, sure, we can keep it just to make it symmetric with 
existing annotation attributes.

  regards,
  Eugene