meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
deprecated_settings [2021/10/19 19:57] – revuskydeprecated_settings [2021/12/21 14:03] (current) – revusky
Line 11: Line 11:
   * **UNICODE_INPUT**: Effectively, this is now always set to true, so it is superfluous, (and thus, ignored.)   * **UNICODE_INPUT**: Effectively, this is now always set to true, so it is superfluous, (and thus, ignored.)
   * **USER_CHAR_STREAM**: This was a setting that allowed you to define your own implementation of the ''CharStream'' interface. In default usage of JavaCC 21, this whole concept is irrelevant, since by default, the generated parser just slurps the whole file into memory at once anyway. See [[https://javacc.com/2020/05/05/gigabyte-is-the-new-megabyte/|The Gigabyte is the new Megabyte]].   * **USER_CHAR_STREAM**: This was a setting that allowed you to define your own implementation of the ''CharStream'' interface. In default usage of JavaCC 21, this whole concept is irrelevant, since by default, the generated parser just slurps the whole file into memory at once anyway. See [[https://javacc.com/2020/05/05/gigabyte-is-the-new-megabyte/|The Gigabyte is the new Megabyte]].
-  * **BUILD_LEXER**: It is rather hard to fathom what the point of this setting ever was. Presumably, the case where you don't build a lexer is the one in which you define your own XXXLexer implementation. However, the USER_DEFINED_LEXER setting (previously called USER_TOKEN_MANAGER) always existed, so it is not clear why this setting was ever needed.+  * **BUILD_LEXER**: It is rather hard to fathom what the point of this setting ever was. On modern hardware, a full rebuild of both the parser and lexer is not very expensive. This kind of thing does not seem to have any value and is really just confusing. 
   * **BUILD_PARSER**: Another bizarrely pointless setting really. If all you want to do is build a lexer, and not a parser, then just don't define any grammatical productions in your grammar and all we build is a lexer!   * **BUILD_PARSER**: Another bizarrely pointless setting really. If all you want to do is build a lexer, and not a parser, then just don't define any grammatical productions in your grammar and all we build is a lexer!
 +  * **DEBUG_LEXER**: This setting, along with ''DEBUG_PARSER'' are removed as of mid-December 2021. It is very hard to imagine current-day developers using this sort of approach, as opposed to using an actual debugger!
 +  * **DEBUG_PARSER**: This is now gone. It is actually not so hard to debug the generated parser since the code is much more readable than before and contains location info to trace back where in the grammar file the generated code originated.
   * **KEEP_LINE_COL**: JavaCC21 always puts location information in Tokens and Node objects. (//Really, why would you ever want to throw away location info?//) For more thoughts on this issue, see [[https://javacc.com/2020/05/05/gigabyte-is-the-new-megabyte/|The Gigabyte is the new Megabyte]].   * **KEEP_LINE_COL**: JavaCC21 always puts location information in Tokens and Node objects. (//Really, why would you ever want to throw away location info?//) For more thoughts on this issue, see [[https://javacc.com/2020/05/05/gigabyte-is-the-new-megabyte/|The Gigabyte is the new Megabyte]].
   * **ERROR_REPORTING**: This was an option that was true by default, but you could turn it off in order to generate a somewhat smaller .class file, except that error messages would be much less informative because of information being thrown away. I did some experimenting and found that the generated XXXParser.class was typically about 10% smaller with ERROR_REPORTING off. The tradeoff looks terrible and, as with KEEP_LINE_COL, it looks utterly foolish to ever turn this off. So, the setting is now gone and the option is always effectively on. (Further note. All the legacy error reporting code is practically rewritten anyway. The prior comment applies in any case. There is no reason for any sane person to want to turn it off.)   * **ERROR_REPORTING**: This was an option that was true by default, but you could turn it off in order to generate a somewhat smaller .class file, except that error messages would be much less informative because of information being thrown away. I did some experimenting and found that the generated XXXParser.class was typically about 10% smaller with ERROR_REPORTING off. The tradeoff looks terrible and, as with KEEP_LINE_COL, it looks utterly foolish to ever turn this off. So, the setting is now gone and the option is always effectively on. (Further note. All the legacy error reporting code is practically rewritten anyway. The prior comment applies in any case. There is no reason for any sane person to want to turn it off.)
   * **SANITY_CHECK**: By default, the parser generator does some various sanity checks before generating the various files. This setting in the legacy JavaCC tool allowed you to turn this off. (//Why would anybody turn this off?//) This setting is gone and is now effectively always true.   * **SANITY_CHECK**: By default, the parser generator does some various sanity checks before generating the various files. This setting in the legacy JavaCC tool allowed you to turn this off. (//Why would anybody turn this off?//) This setting is gone and is now effectively always true.
   * **CACHE_TOKENS**: I never even understood what the point of this setting was. It must have been some kind of //speculative// peephole optimization, except I don't think it was even correct. There would be problems with switches of lexical state in some cases. Also, I doubt it offered any noticeable performance gain. The setting is now gone and is always effectively false. (Which was the default before, which everybody was using anyway.)   * **CACHE_TOKENS**: I never even understood what the point of this setting was. It must have been some kind of //speculative// peephole optimization, except I don't think it was even correct. There would be problems with switches of lexical state in some cases. Also, I doubt it offered any noticeable performance gain. The setting is now gone and is always effectively false. (Which was the default before, which everybody was using anyway.)
 +  * **TOKEN_FACTORY** : This setting has been removed (as of 11/11/2021) since it is really not very useful now that we have INJECT. I doubt it was really very widely used (if at all).
   * **TRACK_TOKENS** : There is no real reason for this setting to exist any more, since, by default, Tokens are added to the AST and they have their line/column information. In fact, all Node objects have line/column information.   * **TRACK_TOKENS** : There is no real reason for this setting to exist any more, since, by default, Tokens are added to the AST and they have their line/column information. In fact, all Node objects have line/column information.
   * **USER_DEFINED_TOKEN_MANAGER** : This setting was removed in October 2021.    * **USER_DEFINED_TOKEN_MANAGER** : This setting was removed in October 2021.