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