[SDU软件工程实践]Blog8-直到HiveParser/debug的困境

2021SC@SDUSC

我们先继续上一次的地方讲，有关debug和对hive外框架的处理最后说。

HiveLexerX到底是什么？

首先我们接着看上一次

我们一点一点看

new ANTLRNoCaseStringStream

这个类的构造器经过了一层调用，结果是这样的

input就算是command，也就是说这个类的构造器实际上就是给这个类输入了一个命令字符串。当然，这个类还有很多其他变量，不过在new过程中完全没用起来就是了。
好，这个就完了。（？大概吧，估计将来还会见）

new HiveLexerX

这个类存在继承

（另提一嘴，ANTLRNoCaseStringStream继承了ANTLRStringStream，ANTLRStringStream继承了CharStream。爸爸的爸爸是爷爷，儿子的儿子是孙子，所以ANTLRNoCaseStringStream也继承了CharStream）
然后，这个new HiveLexerX的过程就十分的混乱，我们一点一点看

这个类继承了HiveLexer，super下一层就转进到HiveLexer

为啥又有super呢？这里还有继承,，继承了Lexer。好，继续往上翻。

好，这次是把同一个CharStream设置为input！到头了……吗？唉？这个RecognizerSharedState虽说是new的，没有和input产生联系，但还是看一眼。

唔……就是附了个值，到最后也是new的新对象，过。

回到开头

也就是说我们能直接获得的信息是：lexer中的input属性是一个ANTLRNoCaseStringStream，lexer的data是命令的字符串，n是长度
state是一个new RecognizerSharedState

TokenRewriteStream

接下来是这个

这个new方法也是层层调用，首先能确定的是以下几点：
tokenSource附上了之前的lexer（HiveLexerX实现了TokenSource接口）
channel为0
以及这个init方法长这样子：

很朴实的初始化？

HiveParser——几千行的常量

直接说结论
input属性是之前的tokens（TokenRewriteStream类）
state是一个new RecognizerSharedState（这我其实有些奇怪啊，之前不是new过了吗……）
然后，HiveParser里有这些private static final的常量……

虽然有TOK_SELECT这样的，释放出很好的信号的变量名，但是一千多个……这也太多了。不过我猜测这很有可能是构成树的关键？

关于debug

这周我在尝试的时候遇到了两个问题：
1.我的虚拟机挺小的，不知道能不能跑IDEA这样的大家伙……
2.hive坏了……
下周的博客就解决hive的问题为主吧，问题挺诡异的，现在还没法详说