0

I'm trying to make a parser for a Java Program's command line arguments, as not to re-invent the wheel I tried looking for a generator that would generate something like that for me, I found people suggesting CLI and JSAP, they seem like great tools but they create objects in run-time, I need my parsing to be static as to not clutter the code with unncessary capabilities (and memory), so what I'm really looking for is a command line parser generator, in that thread I found XTC, Rats, and JavaCC, but they seem like a lot of work and I think that what I need is simpler.

In The end I decided to make my parser using JavaCC, this question is just to make sure that there is no one out there that knows a simpler way...

Thanks

Edit: the JavaCC thread is a dud since it works on character by character, not really suitable for command line parsing

Mystic Odin
  • 269
  • 1
  • 2
  • 13
  • possible duplicate of [Is there a good command line argument parser for Java?](http://stackoverflow.com/questions/367706/is-there-a-good-command-line-argument-parser-for-java) – Stephen C Oct 29 '12 at 02:34
  • The answers to the linked question has **many** examples of command line parser libraries, etc. – Stephen C Oct 29 '12 at 02:35
  • 2
    I am afraid you are doing premature optimization, the root of all evil. Since command-line parser works only once, the fact it create objects in runtime is insignificant. Think of JVM itself, how many objects it creates at start-up. – Alexei Kaigorodov Oct 29 '12 at 02:54

1 Answers1

1

This related SO question has many useful suggestions for command line parser libraries. I want to focus on why a classic parser generator is not a good way to solve the problem.

There are two fundamental reasons:

  1. A command line syntax needs to be simple, easy to remember, consistent with other command line syntaxes in general style / conventions, and has a minimum of syntactic noise. The problem with conventional PGS's is that each grammar is distinct from others, and is burdened with the need for unambiguous parses ... which tends to lead to syntactic noisiness. (OK, if you are disciplined you can avoid these traps, but ...)

    By contrast, the APIs of a typical argument parser library encourage the programmer to use a consistent style; e.g. -x versus --longForm, options first, -- means no more options, and so on. And because the "language" doesn't care about ambiguity, the programmer is free to sort this out informally (without excessive syntax) or simplify the syntax.

  2. Parser generators either produce parse trees or they require you to embed your code into the grammar. Neither of these is ideal for command line parsing, because they both add complexity to the application code to deal with this.

    By contrast, a typical argument parser library creates or populates a flat data structure, which is simpler to deal with.

You also seem to be overly worried about performance and memory usage:

... I need my parsing to be static as to not clutter the code with unncessary capabilities (and memory)

First observation is that it probably doesn't matter. The number and size of the runtime objects is most likely trivial compared to rest of the application ... and all of the hidden stuff that happens during normal JVM startup before the arguments are parsed ... and afterwards.

Second observation is that a PGS-based solution possibly has comparable overheads. In addition to generating a parse tree (for instance), the generated parser also needs to initialize and retain a bunch of grammar-specific parser tables. And of course, the generated parser code tends to be large as well.

Community
  • 1
  • 1
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I realized that PGS based solution is also not very good since the code generator waits for an input stream and often works on character by character, while java arguments are actually passed as string array. – Mystic Odin Oct 29 '12 at 03:55
  • I'm going to profile a parser I coded myself for a couple of parameters and see if it has comparable performance to CLI – Mystic Odin Oct 29 '12 at 04:03
  • 1
    @MysticOdin - I think you still haven't "got" my point and Alexei's. If your parser took 0.01 seconds and CLI took 0.1 seconds, it STILL wouldn't matter. You need to decide 1) in the context of the entire application's runtime, and 2) in the context of the actual performance **requirements** for your application. Spending **days** on optimizing command line parsing when nobody will notice the difference would be a mammoth waste of time. – Stephen C Oct 29 '12 at 04:15
  • I did get your point and Alexei's, specially the "Premature Optimization" thing since this is done only at startup along with a lot of possible overhead from the JVM, and your point about the typical program runtime is in my mind too, I also need to compare the time needed to detect errors in arguments since for my case this is a crucial issue, also the executable jar size, I just want to pursue this issue to the end to have concrete data supporting my decision, thanks a lot for your care to clarify – Mystic Odin Oct 29 '12 at 04:36