BUILDING.txt

[Craig L Russell <Cr...@Sun.COM>]

I'll write up a note for BUILDING.txt, but I'd like to put in some  
more material than "These error messages are to be expected."  
Something like a real explanation of why the .java files appear to be  
out of sync with the source .jj files.

Does anyone know the history here? Is this something that we should  
at some point actually fix in the sources?

Craig

David wrote:
These error messages are to be expected.  I agree BUILDING.txt should
warn people to expect this, I agree it is disconcerting.

David

Craig L Russell wrote:
 > Hi,
 >
 > I ran across an interesting issue while building Derby. I checked out
 > the latest sources and ran ant from the top. I read the ant output  
and
 > found this:
 >
 > genParser:
 >      [echo]   Generating SQL parser...
 >      [java] Java Compiler Compiler Version 4.0 (Parser Generator)
 >      [java] (type "javacc" with no arguments for help)
 >      [java] Reading from file sqlgrammar.jj . . .
 >      [java] Note: UNICODE_INPUT option is specified. Please make sure
 > you create the parser/lexer using a Reader with the correct character
 > encoding.
 >      [java] Warning: ParseException.java: File is obsolete.  Please
 > rename or delete this file so that a new one can be generated for  
you.
 >      [java] Warning: Token.java: File is obsolete.  Please rename or
 > delete this file so that a new one can be generated for you.
 >      [java] Warning: CharStream.java: File is obsolete.  Please  
rename
 > or delete this file so that a new one can be generated for you.
 >      [java] Parser generated with 0 errors and 3 warnings.
 >
 > Thinking I had done something wrong, I followed instructions and  
removed
 > the 3 obsolete files. Now I could not build any more. I got messages
 > like this:
 >
 > genParser:
 >
 > compile:
 >     [javac] Compiling 149 source files to /Users/clr/derby/trunk/ 
classes
 >     [javac]
 > /Users/clr/derby/trunk/java/engine/org/apache/derby/impl/sql/ 
compile/ParserImpl.java:141:

 > cannot find symbol
 >     [javac] symbol  : method ReInit(java.io.Reader,int,int,int)
 >     [javac] location: interface  
org.apache.derby.impl.sql.compile.CharStream
 >     [javac]                     charStream.ReInit(sqlText, 1, 1,
 > LARGE_TOKEN_SIZE);
 >
 > Once I went back and restored the three files to their checked-in
 > versions, everything worked again.
 >
 > This indicates to me that the sources for these three files in
 > sqlgrammar.jj are not in sync with the generated java files.
 >
 > Was this intentional? Should we add a note in BUILDING.txt to explain
 > what is going on?
 >
 > Thanks,
 >
 > Craig
 >
 > Craig Russell
 > clr@apache.org http://db.apache.org/jdo

Craig Russell
clr@apache.org http://db.apache.org/jdo

Re: BUILDING.txt

[Andrew McIntyre <mc...@gmail.com>]

On 8/3/06, Craig L Russell <Cr...@sun.com> wrote:
>
> I'll write up a note for BUILDING.txt, but I'd like to put in some more
> material than "These error messages are to be expected." Something like a
> real explanation of why the .java files appear to be out of sync with the
> source .jj files.
>
> Does anyone know the history here? Is this something that we should at some
> point actually fix in the sources?

A couple of fields and methods were added to the basic classes
generated by JavaCC to allow us to get at substrings being handled by
the parser and IIRC to reset the position pointer of the stream of
characters if we had grabbed characters out of the stream.

JavaCC complains if the version for that flavor of generated file
doesn't have the latest version string as a comment on the first line.
So, I think these starting saying "file is obsolete" with the recent
upgrade from JavaCC 3.1 to JavaCC 4.0.

An interesting note is that ParseException has gone from using
StringBuffer in JavaCC 3.1 to using concatenated Strings in JavaCC
4.0. If compiled by a JDK 1.5 compiler, String concatenation would use
StringBuilder, not StringBuffer. But, hopefully this change is handled
properly by the -source and -target flags in our build.xml files so
that compatiblity with the older VMs is maintained when using the
newer compilers.

Do we want to fix the warnings? Maybe. Maybe a note in BUILDING.txt is
all that is necessary. It is possible to fix the warnings, though.
I've attached a patch to this mail for illustration purposes only,
I've run no tests. It updates the current files to match the latest
generated files, including our additional methods. You can apply the
patch, clobber, and rebuild, and voila, no warnings about obsolete
files.

andrew