On 8/3/06, Craig L Russell <[EMAIL PROTECTED]> 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
javacc_warnings.patch
Description: Binary data
