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
new_settings_in_javacc_21 [2022/02/15 05:22] chamberlainnew_settings_in_javacc_21 [2022/02/15 05:28] (current) chamberlain
Line 1: Line 1:
 Here is a list of settings that exist in JavaCC 21 but are not (and never were) present in the legacy JavaCC tool: Here is a list of settings that exist in JavaCC 21 but are not (and never were) present in the legacy JavaCC tool:
  
-  * **BASE_NAME** This option is used to set the name of the parser, lexer, constants, and NFA data files instead of using the default naming convention that prefixes these files with the name of the grammar file. If this option is set to an empty string (BASE_NAME="";) then these filenames will not receive a prefix. +  * **BASE_NAME** This option is used to set the name of the parser, lexer, constants, and NFA data files instead of using the default naming convention that prefixes these files with the name of the grammar file. If this option is set to an empty string (BASE_NAME="";) then these filenames will not receive a prefix. See the PARSER_CLASS, LEXER_CLASS, and CONSTANTS_CLASS settings to individually specify the names for these classes.
   * **BASE_NODE_CLASS** When defined, this option allows you to specify the name of the base node from BaseNode to a name that you prefer, such as SimpleNode. This class implements the Node interface and is extended by the production classes generated by JavaCC.   * **BASE_NODE_CLASS** When defined, this option allows you to specify the name of the base node from BaseNode to a name that you prefer, such as SimpleNode. This class implements the Node interface and is extended by the production classes generated by JavaCC.
   * **BASE_SRC_DIR** This supersedes the older OUTPUT_DIRECTORY setting. Files are generated //relative// to the BASE_SRC_DIR, i.e. taking into account the package naming. If this is unset, BASE_SRC_DIR is assumed to be the directory where the grammar is.   * **BASE_SRC_DIR** This supersedes the older OUTPUT_DIRECTORY setting. Files are generated //relative// to the BASE_SRC_DIR, i.e. taking into account the package naming. If this is unset, BASE_SRC_DIR is assumed to be the directory where the grammar is.
Line 14: Line 14:
   * **MINIMAL_TOKEN** Default is not set (false) Token Chaining is supported by adding two fields to Tokens. If token chaining is _not_ required, define this option to skip adding these two additional fields.   * **MINIMAL_TOKEN** Default is not set (false) Token Chaining is supported by adding two fields to Tokens. If token chaining is _not_ required, define this option to skip adding these two additional fields.
   * **PARSER_CLASS** This option is used to set the name of the generated parser file instead of using the default file name based on the grammar filename.   * **PARSER_CLASS** This option is used to set the name of the generated parser file instead of using the default file name based on the grammar filename.
 +  * **PARSER_PACKAGE** By default, all classes are generated with no package (default package). When this option is defined, all generated classes will have the specified package inserted at the top of the files. This option improves the organization of source code in large non-trivial projects.
   * **PRESERVE_LINE_ENDINGS** This is now off by default. That means that all Windows/DOS style line endings (\r\n) are converted to UNIX/MacOS style (\n) internally when the file is read in. Note, by the way, that one advantage of this and the TABS_TO_SPACES option is that if you convert tabs to spaces and line endings to \n then your grammar's lexical specification can be a bit simpler. And your own code that runs over Tokens and Nodes. Your code can just assume that any line endings are a simple \n and and your horizontal whitespace is just spaces, not a mix of tabs and spaces, independently of what platform the generated code is running on.   * **PRESERVE_LINE_ENDINGS** This is now off by default. That means that all Windows/DOS style line endings (\r\n) are converted to UNIX/MacOS style (\n) internally when the file is read in. Note, by the way, that one advantage of this and the TABS_TO_SPACES option is that if you convert tabs to spaces and line endings to \n then your grammar's lexical specification can be a bit simpler. And your own code that runs over Tokens and Nodes. Your code can just assume that any line endings are a simple \n and and your horizontal whitespace is just spaces, not a mix of tabs and spaces, independently of what platform the generated code is running on.
   * **SMART_NODE_CREATION** This is the default behavior, so you would have to explicitly turn it off. It means that if no JJTree-style tree-building annotation is used, then a new Node will be created if there are more than one Nodes on the stack. So, a production like '' A (B)* '' will create a new Node if there are one or more B's after the A. If there is only an ''A'' then the production will just leave it on the stack. It is our belief that this is the behavior that most people would want most of the time.   * **SMART_NODE_CREATION** This is the default behavior, so you would have to explicitly turn it off. It means that if no JJTree-style tree-building annotation is used, then a new Node will be created if there are more than one Nodes on the stack. So, a production like '' A (B)* '' will create a new Node if there are one or more B's after the A. If there is only an ''A'' then the production will just leave it on the stack. It is our belief that this is the behavior that most people would want most of the time.