我正在尝试为Java程序的命令行参数创建一个解析器，因为我没有重新发明轮子，我试图寻找一个能为我生成类似内容的生成器，我发现人们建议使用CLI和JSAP，它们看起来像是很棒的工具，但它们在运行时创建对象，我需要我的解析是静态的，不要用不必要的功能（和内存）来混淆代码，所以我真正需要的是命令行解析器生成器，在那个帖子中我找到了XTC，Rats和JavaCC，但它们似乎很多工作，我认为我需要的更简单。
最后我决定使用JavaCC创建我的解析器，这个问题只是为了确保没有人知道更简单的方法......
由于
编辑：JavaCC线程是一个dud，因为它逐字符工作，不适合命令行解析
答案 0 :(得分：1)
这个related SO question对命令行解析器库有很多有用的建议。我想关注为什么经典的解析器生成器不是解决问题的好方法。
有两个基本原因：
命令行语法需要简单，易于记忆，与一般样式/约定中的其他命令行语法一致，并且具有最小的语法噪音。传统PGS的问题在于每种语法都与其他语法不同，并且需要明确的解析......这往往会导致句法噪音。 （好吧，如果你受到纪律处分，你可以避免这些陷阱，但......）
相比之下，典型的参数解析器库的API鼓励程序员使用一致的样式;例如-x与--longForm，首先是选项，--表示没有其他选项，依此类推。而且由于“语言”并不关心歧义，程序员可以自由地对此进行非正式排序（没有过多的语法）或简化语法。
Parser生成器要么生成解析树，要么要求您将代码嵌入到语法中。这些都不是命令行解析的理想选择，因为它们都会增加应用程序代码的复杂性来处理这个问题。
相比之下，典型的参数解析器库创建或填充平面数据结构，这更容易处理。
您似乎也过分担心性能和内存使用情况：
...我需要我的解析是静态的，以免杂乱的能力（和内存）混乱代码
首先观察到它可能并不重要。与应用程序的其余部分相比，运行时对象的数量和大小很可能是微不足道的...以及在解析参数之前正常JVM启动期间发生的所有隐藏事物......以及之后。
第二个观察结果是基于PGS的解决方案可能具有可比较的开销。除了生成解析树（例如）之外，生成的解析器还需要初始化并保留一堆特定于语法的解析器表。当然，生成的解析器代码也会很大。