[JSR308] Locations for annotations on types

Tom Ball Tom.Ball at Sun.COM
Mon Feb 26 11:23:31 EST 2007


Michael Ernst wrote:
>>> They are an implicit mention of a type.  For example, the method
>>> > >
>>> > >   PrintStream.println(String)
>>> > >
>>> > > has two parameters.  Java provides a shorthand that permits one of them to
>>> > > be implicit, but both parameters should be able to be annotated.
>> > 
>> > Those are (actual) arguments, not (formal) parameters.
> 
> There are both two formal parameters and two actual arguments -- the number
> of formals and actuals is always the same.  I was speaking of the formal
> parameters, because annotations apply to parameters, not to arguments.

I don't believe that is true:  the Java syntax doesn't "provide a 
shorthand", it is an essential aspect of the language that instance 
methods work on a specific object instance.  Yes, at the JVM level the 
instance is passed as the first parameter, but that is because the JVM 
is supposed to be language-independent.  The Java syntax obviously is 
not language-independent, so the number of method parameters it supports 
may be different than the number of JVM arguments.  Regardless of 
semantic arguments regarding what the definitions of "formal" and 
"actual" parameters are, at the Java syntax and JVM levels they are as 
Neal described.

>> In a class, the
>> receiver is always the class itself; the receiver is the same type for all
>> methods in a class.
> 
> You mean to say that "the receiver is the same Java type".  The qualified
> type may differ.  In a qualified type system -- and for other uses as well
> -- there may be a need to annotate the receiver.  Examples have been given
> before, including in my message.

We *are* working on a syntax specific to Java, aren't we?  This and 
other responses I've read suggest a desire to define something broader 
than is required for Java and its limits.  Why that can be wonderful 
late-night conference discussion fodder, we need to focus on what is 
only necessary for Java if there is to be any hope of this JSR making a 
contribution to the Java platform.

Tom



More information about the JSR308 mailing list