[antlr-interest] Antlr-Eclipse Problems

Robert Colquhoun rjc at trump.net.au
Thu Apr 17 09:03:31 PDT 2003


Hello Everybody

Following up my own post their is a context diff file here:
         http://www.trump.net.au/~rjc/antlr.diff.gz

(It was ~16k lines too big to attach)

The patch hacked out over last few hours moves all the antlr classes out of 
the default namespace.  This means no clashing with user defined classes in 
actions etc and the eclipse compiler no longer generates lots of warnings 
on the generated code.

There is an compatibility issue though, alot of grammars expect certain 
classes to be available ie Token, AST.  To fix this either use a fully 
qualified name(ie prefix with 'antlr.') or add the appropriate imports to 
the header section of your grammar(ie import antlr.Token;)

To rebuild antlr i had to create a build script:
$ cat build
find antlr -name '*.class' -exec rm {} \;
javac -classpath . antlr/build/*.java
javac -classpath . antlr/J*.java
java -classpath . antlr.build.Tool build
java -classpath . antlr.build.Tool jar

I did this in a hurry, and its late at night now...so don't go copying this 
code straight into your production grammars or anything without double 
checking.

  - Robert

At 10:27 PM 17/04/2003 +1000, Robert Colquhoun wrote:
>Hello,
>
>I have just tried using antlr plugin for eclipse
>(http://sourceforge.net/projects/antlreclipse/) with the recently released
>eclipse 2.1 (http://www.eclipse.org/).
>
>By default the eclipse compiler is a bit stricter than the default java
>compiler.  The generated antlr java code now seems to produce a large
>number of warnings mainly "unused import" around 180 errors for my project,
>but also "unused variable" if you have that warning enabled, around 100
>errors for the project.
>
>An easy fix is just to just disable the particular warnings for the
>project.  But i was wondering if the antlr code generation could be made a
>bit smarter ie *TokenTypes.java files are just a set of integer constants
>they cant possibly need any of the imports provided.
>
>Anyway i started looking at the generated code and it occurred to me really
>you shouldn't be pulling any of the antlr namespace via imports into the
>code because it can interfere with the user code in the actions.
>
>ie antlr imports its own BitSet class, if the user wants to use
>java.util.BitSet the names will clash.
>
>I can provide a patch so that no antlr classes are imported by simply using
>fully qualified names in the generated code.  This might make the generated
>code marginally longer slightly harder to read but it will fix the eclipse
>problem and remove the chance of names clashing.
>
>Is this worthwhile patch?
>
>   - Robert
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




More information about the antlr-interest mailing list