Am I missing something here?

[Jonathan Revusky-3]

I just noticed in Javacc.jj that the definition of the CompilationUnit
production is:
"
   [ LOOKAHEAD( ( Annotation() )* "package" ) PackageDeclaration() ]
   ( ImportDeclaration() )*
   ( TypeDeclaration() )*


That's wrong, isn't it?

The (Annotation())*  should be in before the TypeDeclaration() (and
after the ImportDeclarations) not before the package declaration, right?

JR


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tom Copeland]

On Fri, 2008-05-16 at 20:44 +0200, Jonathan Revusky wrote:

> I just noticed in Javacc.jj that the definition of the CompilationUnit
> production is:
> "
>    [ LOOKAHEAD( ( Annotation() )* "package" ) PackageDeclaration() ]
>    ( ImportDeclaration() )*
>    ( TypeDeclaration() )*
>
>
> That's wrong, isn't it?
>
> The (Annotation())*  should be in before the TypeDeclaration() (and
> after the ImportDeclarations) not before the package declaration, right?

I think it's correct... a package can have annotations:

http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.4.1

Yours,

Tom



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jonathan Revusky-3]

Tom Copeland wrote:

> On Fri, 2008-05-16 at 20:44 +0200, Jonathan Revusky wrote:
>> I just noticed in Javacc.jj that the definition of the CompilationUnit
>> production is:
>> "
>>    [ LOOKAHEAD( ( Annotation() )* "package" ) PackageDeclaration() ]
>>    ( ImportDeclaration() )*
>>    ( TypeDeclaration() )*
>>
>>
>> That's wrong, isn't it?
>>
>> The (Annotation())*  should be in before the TypeDeclaration() (and
>> after the ImportDeclarations) not before the package declaration, right?
>
> I think it's correct... a package can have annotations:
>
> http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.4.1

That's what the lawyers say. (First time I saw that.)

But javac says something else:

   [javac] Compiling 143 source files to
/home/revusky/workspace/javacc/classes
    [javac]
/home/revusky/workspace/javacc/src/org/javacc/parser/CodeFragment.java:1:
package annotations should be in file package-info.java
    [javac] @SuppressWarnings("serial")
    [javac] ^
    [javac] 1 error

(And eclipse says that's an error too.) My understanding was that an
annotation on a package had to be in a special package-info.java file.

In other matters, I see that annotations are handled under Modifiers()
so JavaCC considers that:

public @SuppressWarnings("unused") void unused() {}

Surprisingly (to me) both javac and eclipse agree that the above is
A-OK. OTOH, JavaCC thinks that the following is okay too.

public void @SuppressWarnings("unused") unused() {}

Neither javac nor eclipse agree.

I think the business of annotating packages (except in
package-info.java) may have been an earlier draft of the Java 1.5
language that got superseded.

As for the above, sandwiching an annoation between two modifiers, I am
not sure what the rule is. It makes no sense to me. If you can put hte
annotation before all the modifiers, sandwich them between the
modifiers, why not put them after all the modifiers? But it doesn't work.

JR
> Yours,
>
> Tom


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Nathan D. Ryan]

On 16 May, 2008, at 14.36, Jonathan Revusky wrote:

> But javac says something else:
>
>   [javac] Compiling 143 source files to
> /home/revusky/workspace/javacc/classes
>    [javac]
> /home/revusky/workspace/javacc/src/org/javacc/parser/
> CodeFragment.java:1:
> package annotations should be in file package-info.java
>    [javac] @SuppressWarnings("serial")
>    [javac] ^
>    [javac] 1 error
>
> (And eclipse says that's an error too.) My understanding was that an
> annotation on a package had to be in a special package-info.java file.
>

Annotations should be in package-info.java. As per the specification,  
this is not a requirement. However, not all annotations can be placed  
on all kinds of declarations. SuppressWarnings, in particular, is not  
applicable for annotating a package declaration. See the documentation  
for java.lang.annotation.Target for more information.

> In other matters, I see that annotations are handled under Modifiers()
> so JavaCC considers that:
>
> public @SuppressWarnings("unused") void unused() {}
>
> Surprisingly (to me) both javac and eclipse agree that the above is
> A-OK. OTOH, JavaCC thinks that the following is okay too.
>
> public void @SuppressWarnings("unused") unused() {}
>
> Neither javac nor eclipse agree.
>

I had not seen that the Java grammar that comes with JavaCC would  
permit that, though it is possible. Note that, in general, the grammar  
used to parse a programming language is usually a superset of the  
syntax defined by the specification of the programming language. This  
is done for the dual purposes of convenience and performance. Think of  
the Java grammar as recognizing a superset of the Java syntax.

> As for the above, sandwiching an annoation between two modifiers, I am
> not sure what the rule is. It makes no sense to me. If you can put hte
> annotation before all the modifiers, sandwich them between the
> modifiers, why not put them after all the modifiers? But it doesn't  
> work.
>

Annotations can be freely mingled among other modifiers (e.g., public,  
static, etc.), though it is considered poor style if they are not  
grouped before the language modifiers. Note that void is a type  
specifier, not a modifier.

Nathan


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Jonathan Revusky-3]

Nathan D. Ryan wrote:

> On 16 May, 2008, at 14.36, Jonathan Revusky wrote:
>
>> But javac says something else:
>>
>>   [javac] Compiling 143 source files to
>> /home/revusky/workspace/javacc/classes
>>    [javac]
>> /home/revusky/workspace/javacc/src/org/javacc/parser/CodeFragment.java:1:
>> package annotations should be in file package-info.java
>>    [javac] @SuppressWarnings("serial")
>>    [javac] ^
>>    [javac] 1 error
>>
>> (And eclipse says that's an error too.) My understanding was that an
>> annotation on a package had to be in a special package-info.java file.
>>
>
> Annotations should be in package-info.java. As per the specification,
> this is not a requirement. However, not all annotations can be placed on
> all kinds of declarations. SuppressWarnings, in particular, is not
> applicable for annotating a package declaration. See the documentation
> for java.lang.annotation.Target for more information.

I just tested it and I explicitly added ElementType.PACKAGE as a
permissible target to the annotation freemarker.template.Paramenters

and stuck it in front of a package declaration and I still get this error:

/Users/revusky/workspace/freemarker/src/freemarker/ext/util/IdentityHashMap.java:52:
package annotations should be in file package-info.java
     [javac] @freemarker.template.Parameters("foobar")

 From javac 1.5, javac 1.6, and eclipse. None of them accept it, so
AFAICS, the legal reality is that you can do it, but the practical
reality is that you can't. : -)

<shrug>

>
>> In other matters, I see that annotations are handled under Modifiers()
>> so JavaCC considers that:
>>
>> public @SuppressWarnings("unused") void unused() {}
>>
>> Surprisingly (to me) both javac and eclipse agree that the above is
>> A-OK. OTOH, JavaCC thinks that the following is okay too.
>>
>> public void @SuppressWarnings("unused") unused() {}
>>
>> Neither javac nor eclipse agree.
>>
>
> I had not seen that the Java grammar that comes with JavaCC would permit
> that, though it is possible. Note that, in general, the grammar used to
> parse a programming language is usually a superset of the syntax defined
> by the specification of the programming language. This is done for the
> dual purposes of convenience and performance. Think of the Java grammar
> as recognizing a superset of the Java syntax.

Yeah, I realize that. In fact, there's no absolute functional
requirement that the parser generator tell you anything about bad code
in your actions and so on. Some parser generators just let you put
anything in there as long as the parentheses balance and leave it to the
compiler step to tell you it's wrong.

And it's not a very important case. But it seems it would be better if
it told you this was a mistake before you compiled it.

>
>> As for the above, sandwiching an annoation between two modifiers, I am
>> not sure what the rule is. It makes no sense to me. If you can put hte
>> annotation before all the modifiers, sandwich them between the
>> modifiers, why not put them after all the modifiers? But it doesn't work.
>>
>
> Annotations can be freely mingled among other modifiers (e.g., public,
> static, etc.), though it is considered poor style if they are not
> grouped before the language modifiers. Note that void is a type
> specifier, not a modifier.

Oh, okay. That's right. Thanks.

JR

>
> Nathan


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...