我正在用flex编写Java的词法分析器。Java规范说：
“即使结果最终不能正确编写程序，但每个步骤都使用最长的翻译，而另一种词法翻译将使用这种翻译。有一个例外：如果词法翻译发生在类型上下文中（第4.11节），输入流具有两个或多个连续的>字符，后跟一个非>字符，然后每个>字符必须转换为数字比较运算符>的标记。“
那么如何区分右移运算符和<List<List [>>中的类似内容？
原始Java泛型提议（JSR-14）需要修改参数化类型的Java语法，以便在可能有多个尖括号的情况下接受>>和>>>。 （我找不到JSR-14的有用权威链接，但Gilad Bracha的GJ specification仍可在他的网站上找到；语法修改请参见第2.3节。）
据我所知，这些修改从未正式纳入任何Java标准中；最终，JLS8将更改合并到您在问题中引用的词法分析描述。 （请参见JDK-8021600，它也复制了最初提出的复杂语法。）
[Bracha等人提出的语法修改可以使用，但是您可能会发现它们使合并其他语法更改更加复杂。 （我还没有真正深入地研究过它，因此对于当前的Java语言规范来说，这实际上可能不是问题。但是对于以后的版本，这仍然可能是一个问题。）
虽然上下文词法分析的确允许JLS中实际使用的语法更简单，但无疑为词法分析带来了困难。一种可能的方法是通过使用scannerless parser完全放弃词法分析。当然可以，但是您将无法在Bison / Flex模型中完成此任务。另外，您可能会发现支持无扫描程序分析所需的某些修改也要求对已发布的语法进行不重要的更改。
[另一种可能性是通过并入中间规则动作（MRA）来使用来自解析器的词法反馈，该动作会在进入和退出类型上下文时打开和关闭“类型上下文”标志。 （第4.11节中提供了类型上下文的完整列表，可用于在语法中找到合适的位置。）如果尝试这样做，请注意，由于语法分析程序通常会导致MRA的执行与词法分析不完全同步。需要先行令牌来决定是否减少MRA。您通常需要在语法中比您想象的更早放置一个MRA符号，以便它实际上在需要的时候生效。
[另一种可能是永远不要将>>和>>>识别为令牌。相反，词法分析器可以返回两个不同的>标记，当下一个直接字符为>时使用一个标记：
>/> { return CONJUNCTIVE_GT; }
> { return INDEPENDENT_GT; }
/* These two don't need to be changed. */
>>= { return SHIFT_ASSIGN; }
>>>= { return LONG_SHIFT_ASSIGN; }
然后您可以修改语法以识别>>和>>>运算符，同时允许将>的任何一种形式用作右尖括号：
shift_op : CONJUNCTIVE_GT INDEPENDENT_GT
long_shift_op: CONJUNCTIVE_GT INDEPENDENT_GT INDEPENDENT_GT
close_angle : CONJUNCTIVE_GT | INDEPENDENT_GT
这应该起作用（尽管我没有尝试过），但是它不能与Bison / Yacc运算符优先级机制配合使用，因为您不能为非终结符声明优先级。因此，您需要使用带有显式运算符优先级规则的表达式语法，而不是使用带有优先级声明的模棱两可的语法。