静态Java命令行解析器生成器

我试图为Java程序的命令行参数制作一个解析器，为了不重新发明轮子，我试图寻找一个生成器，为我生成类似的东西，我发现有人建议使用CLI和JSAP，它们看起来像是很棒的工具，但它们在运行时创建对象，我需要我的解析是静态的，这样就不会用不必要的功能（和内存）把代码弄得乱七八糟，所以我真正想要的是一个命令行解析器生成器，在这个线程中我找到了XTC、Rats和JavaCC，但它们似乎需要大量的工作，我认为我需要的是更简单的

最后，我决定使用JavaCC制作解析器，这个问题只是为了确保没有人知道更简单的方法

谢谢

编辑：JavaCC线程是无用的，因为它可以逐个字符地工作，不太适合命令行解析

这对命令行解析器库有很多有用的建议。我想重点讨论为什么经典解析器生成器不是解决问题的好方法

有两个根本原因：

命令行语法需要简单、易于记忆、与一般样式/约定中的其他命令行语法一致，并且具有最小的语法干扰。传统PGS的问题在于，每种语法都不同于其他语法，并且需要进行明确的语法分析。。。这往往会导致句法噪音。（好的，如果你有纪律，你可以避免这些陷阱，但是…）

相比之下，典型参数解析器库的API鼓励程序员使用一致的风格；e、 g.

-x

与

-longForm

相比，选项优先，

--

意味着没有更多选项，依此类推。由于“语言”不关心歧义，程序员可以随意地对其进行非正式分类（不需要过多的语法）或简化语法

解析器生成器要么生成解析树，要么要求您将代码嵌入语法。这两种方法都不适用于命令行解析，因为它们都增加了应用程序代码处理此问题的复杂性

相比之下，典型的参数解析器库创建或填充平面数据结构，这更容易处理

---

您似乎还过度担心性能和内存使用：

。。。我需要我的解析是静态的，这样就不会用不必要的功能（和内存）把代码弄得乱七八糟

第一个观察结果是，这可能并不重要。与应用程序的其余部分相比，运行时对象的数量和大小很可能微不足道。。。在解析参数之前，在正常JVM启动期间发生的所有隐藏内容。。。然后呢

---

第二个观察结果是，基于PGS的解决方案可能具有类似的开销。除了生成解析树（例如），生成的解析器还需要初始化和保留一组特定于语法的解析器表。当然，生成的解析器代码也往往很大。

链接问题答案的可能重复有许多命令行解析器库等示例。恐怕您正在进行过早优化，这是万恶之源。因为命令行解析器只工作一次，所以它在运行时创建对象的事实并不重要。想想JVM本身，它在启动时创建了多少个对象。我意识到基于PGS的解决方案也不是很好，因为代码生成器等待输入流，并且经常逐个字符地工作，java参数实际上是以字符串数组的形式传递的，我将分析一个解析器，我自己编写了几个参数，看看它的性能是否与字符串数组相当CLI@MysticOdin-我想你还没有“理解”我和阿列克谢的观点。如果您的解析器需要0.01秒，而CLI需要0.1秒，那么这仍然无关紧要。您需要决定1）在整个应用程序运行时的上下文中，以及2）在应用程序的实际性能需求上下文中。在没有人会注意到差异的情况下，花上几天时间优化命令行解析将是巨大的时间浪费。我确实理解了你和Alexei的观点，特别是“过早优化”的事情，因为这只在启动时进行，而且JVM可能会带来很多开销，你关于典型程序运行时的观点也在我的脑海中，我还需要比较检测参数错误所需的时间，因为对于我的案例来说，这是一个关键问题，也是可执行jar的大小，我只想把这个问题一直讨论到最后，以获得支持我决定的具体数据，非常感谢你的关注