java调用cobol_使用Java解析Java / COBOL / VB等代码

解析器(因此解析器生成器提供的机器)必须有一些意思来处理无效的源文件。因此，每个解析器(和解析器生成器)都选择了一些方法来管理语法错误。

大多数人提供的简单解决方案只是在遇到此类错误时抛出异常。调用解析器的用户代码必须捕获此异常并使用中止的解析。一个更复杂的解决方案，让解析器报告语法错误，但从错误中恢复并继续解析;如果您还希望获得可用的树，那么任何此类恢复必须在错误点的节点上使用某种标记来处理AST构建。大多数解析器生成器都会提供某种语法恢复，但让您自己处理AST以构建此类错误。这样的解析器恢复逻辑相对难以构建，如果不成为解析器错误恢复专家，并且对特定解析器生成器的自定义更改支持代码，您可能无法自己完成。

我并不是特别熟悉JavaCC(或其他大多数其他解析器生成器)，所以我不知道它是否这样做。显然，检查文档。如果您没有所需的错误处理支持，请转到另一个拥有它的生成器。

我怀疑你真正的问题实际上是让语法适合你的任务。没有人拥有“Java”或“COBOL”;它们具有特定的方言，例如Java 1.5或IBM Enterprise COBOL或VB6。根据我的长期经验，这些与您期望的基本语言有很大不同。您可以希望您可以获得的这些语法将起作用(包括错误恢复)，以便您能够解析每个语言的各种方言，但通常您会从一个方言中的代码中获得大量错误。不符合你想要的语法。 (对于具有EBCDIC源文件的IBM Enterprise COBOL代码，您将如何处理第72列中的卡号？)因此，您真的需要一个具有大量解析器来处理各种方言的工具，这应该会推动您的选择IMHO。

我认为ANTLR有很多语言定义(超过JavaCC)，所以它有资格。然而，该站点的许多语法都是实验性的或未完成的(有些非常好)，所以你得到了一些运气。

我们的DMS Software Reenginering Toolkit有a lot of grammars，我们认为我们的任务是提高这些生产质量。我们也不完美，但我们的语法往往已经在大量的代码上进行了测试，并且支持各种方言。内置错误恢复，如果错误数小于指定阈值，则会返回树(AST中包含错误节点)。 DMS还处理令人讨厌的问题，例如字符编码(我们做了很多种，包括80列EBCDIC，其中第72列中的卡号用于IBM COBOL和JCL)。 DMS可能不是你想要的;例如，它不是基于Java的。但我们试图通过提供大量机制来支持解析后任务(例如您想要做的事情)来弥补这一点。该机制包括对构建符号表，提取控制和数据流，匹配模式以及应用源到源转换等的支持。但这是您的权衡。