javacc 会根据 parser.jj 中定义的相互穿插的 Token、Java 代码来自动生成 org.apache.calcite.sql.parser.impl.SqlParserImpl 的代码。本文期望以一个简单的 Select 语句为例来说清楚 Sql 语句、Sql 语法定义、SqlParser 之间的关系。
sql 文本如下：
select * from emp where empno > 5 and gender = 'F'
Parser.jj（语法定义文件）和类 SqlParserImpl 中的 SqlSelect 部分定义如下（左为 Parser.jj、右为 SqlParserImpl 类），SqlParserImpl 是由 JavaCC 根据 Parser.jj 定义的语法自动生成，自动生成说白了也就是根据什么样的语法定义生成什么样的 java 代码，我们希望搞明白的就是这样的映射关系：
一、方法声明
会根据
SqlSelect SqlSelect()
生成
final public SqlSelect SqlSelect() throws ParseException
规则也很简单：头加 final public，尾加 throws ParseException
二、Java 代码调用
在 Parser.jj 中，JavaCC 对于 Java 代码调用是直接将其复制到 Parser 的相应位置
2.1、声明/初始化
在 Parser.jj 中，使用 {} 包围的部分都是代码声明，这部分代码会被直接 Copy 为 Parser 相应的代码，如：
这部分代码的作用是声明用于声明一些局部变量，这些局部变量会通过后续的 Token 解析和代码调用来赋值，最终用于构造 SqlSelect
2.2、代码调用
如下箭头所指即语法定义中的代码调用被直接复制到 Parser 的相应位置
三、Token 校验
在 Parser.jj 中定义了 token < SELECT: "SELECT" >，在 Parser.jj 中定义的语法要去匹配这个 Token，则在相应的位置写一个 <SELECT> 即可，JavaCC 会在 Parser 的相应位置增加一行 jj_consume_token(SELECT) 方法。
我们知道，词法解析器会将一段 Sql 解析为一个 Token list（有序的），当我们拿一组 Token 去匹配一段语法定义时，每次遇到语法中如上所述的 Token 定义（我们这里称之为 expectedToken(s)），就会从 Token list 中取出一个或多个连续的 Token（我们称之为 actualToken(s)），会去校验实际的和期望的 kind 是否一致：
- 如果两者类型一致，继续往下走代码生成
- 如果两者类型不一致，说明 Sql 文本（可能是局部的）与当前的定义不匹配，抛异常
jj_consume_token 的主要实现逻辑如下（去除了一些非关键代码）：
// SELECT 的 kind 值为 489
final private Token jj_consume_token(int kind) throws ParseException {
Token oldToken;
if ((oldToken = token).next != null) {
// 只要不是最后一个 token，取 next Token 为当前 token；即将 Token 往后移一位。
// token 初始值为 null，第一次往后移一位后得到的是 sql 即系出来的 Token list 的第一个
// 在本例中为 SELECT
token = token.next;
} else {
token = token.next = token_source.getNextToken();
}
if (token.kind == kind) {
// 真实的 Token 类型与期望的 Token 类型相同，则校验通过
return token;
} else {
// 真实的 Token 类型与期望的 Token 类型不同，则校验不通过，并抛异常
token = oldToken;
jj_kind = kind;
throw generateParseException();
}
}
举几个例子，比如：<SELECT> 会生成 jj_consume_token(SELECT) 代码，在 SqlSelect() 的语法定义中，是定义的第一个 Token，所以这里检查的是第一个 Token 是不是 SELECT；而且这里是单个、必选的，不是可能是多个或者可选的
关于 Token 校验更加复杂的情况，我们将在后文中介绍
四、正则相关
4.1、可选
// 使用正则的 [] 表示这一部分是可选的，这部分包含了 token <HINT_BEG> 和 <COMMENT_END> 以及两者之间的方法调用
// 如 /*+ NO_HASH_JOIN, RESOURCE(mem='128mb', parallelism='24') */
// - **/*+** 即 <HINT_BEG>
// - ***/** 即 <COMMENT_END>
// - **NO_HASH_JOIN, RESOURCE(mem='128mb', parallelism='24')** 会喂给 CommaSepatatedSqlHints(hints) 的语法、代码用来为 hints 赋值
[
<HINT_BEG>
CommaSepatatedSqlHints(hints)
<COMMENT_END>
]
将生成如下代码，在语法定义中使用正则 [] 和 Token 来定义可选部分是怎么样的，在 Parser 中先检查下一个 Token 类型是否符合再调用相应方法
// jj_ntk 表示 next token
// - 若为 -1，表示刚开始遍历 token，往后移动一位拿到第一个 token
// - 若不为 -1，表是已经拿到了 next token
// 总结来说 (jj_ntk==-1)?jj_ntk():jj_ntk 就是拿到下一个 token
switch ((jj_ntk==-1)?jj_ntk():jj_ntk) {
// 如果下一个 token 是 HINT_BEG，则进入相应的分支流程
case HINT_BEG:
// 校验 token 类型
jj_consume_token(HINT_BEG);
CommaSepatatedSqlHints(hints);
// 校验 token 类型
jj_consume_token(COMMENT_END);
break;
default:
jj_la1[29] = jj_gen;
;
}
4.2、0 次或 1 次
(
<STREAM> {
keywords.add(SqlSelectKeyword.STREAM.symbol(getPos()));
}
)?
将生成如下代码，在语法中使用正则 (...)? 表示只出现 0 次或 1 次，在这一点上是和用 [] 表示效果相同，我们看下面的 switch case 的实现也能验证这一点。其余部分也是 Token 的校验和代码调用
switch ((jj_ntk==-1)?jj_ntk():jj_ntk) {
case STREAM:
jj_consume_token(STREAM);
keywords.add(SqlSelectKeyword.STREAM.symbol(getPos()));
break;
default:
jj_la1[30] = jj_gen;
;
}
4.3、或逻辑
(
<DISTINCT> {
keywords.add(SqlSelectKeyword.DISTINCT.symbol(getPos()));
}
| <ALL> {
keywords.add(SqlSelectKeyword.ALL.symbol(getPos()));
}
)?
将生成如下代码，在语法定义中：
- 使用
(...)?来表示可选的，所以在生成的代码中，使用CASE ALL: CASE DISTINCT来表达可选- 下一个 Token 是 ALL 或 DISTINCT 则进入分支流程；否则进入 default
- 在内部，语法定义中使用 | 表示或逻辑，在生成的代码中使用
switch、case来表达
switch ((jj_ntk==-1)?jj_ntk():jj_ntk) {
case ALL:
case DISTINCT:
switch ((jj_ntk==-1)?jj_ntk():jj_ntk) {
case DISTINCT:
jj_consume_token(DISTINCT);
keywords.add(SqlSelectKeyword.DISTINCT.symbol(getPos()));
break;
case ALL:
jj_consume_token(ALL);
keywords.add(SqlSelectKeyword.ALL.symbol(getPos()));
break;
default:
jj_la1[31] = jj_gen;
jj_consume_token(-1);
throw new ParseException();
}
break;
default:
jj_la1[32] = jj_gen;
;
}
除了上面介绍的一些 pattern，还有更多的，但是基于上面介绍的，相信看懂其他的形式也不是问题，这里就不再一个个介绍了
