Java Parser-Generator for these requirements

Question

I have been working on developing a script language which ports methods from the java.awt.Graphics class into commands like

setcolor_0,127,214,255 //R,G,B,Alpha

or

fillrect_50,25,100,75 //x,y,w,h

into a picture, so that I could avoid having to write an entire program every time I wanted to create a certain image. The language itself is currently limited to pseudofunctions and commands (mapped directly to Graphics method calls), plus a few output specifiers as a header to each script, but I want to add more. The script is processed in one program which serves as both parser and interpreter, but my method of processing the input Strings directly is inadequate for what I want to do.

While I have searched and found plenty of parser and lexer generators, I keep running into the same two problems with the parser-generators, that being either

1. The generated parser will require some form of runtime dependency(/-ies) which only the generator can provide (e.g.: Beaver's products needing its own runtime files), or
2. The generator does not appear to have been fully developed, or if this not the case, then the generator still makes at least one disagreeable assumption. (e.g.: Jay's method of generating source code without enclosing class markings and assumption that all classes will be in the same file.)

So in addition to avoiding these things, I am looking for a parser-generator which also has plenty of open documentation (which is why I would like to steer clear of ANTLR), and which outputs Java source code (I would prefer that the output be for as recent a version of Java as is possible, but that is not very important to me).

tl;dr: I need a parser-generator which:

1. Is available along with plenty of documentation (external or otherwise) at no cost to myself.
2. Builds a parser
   1. that does not require external dependencies to run,
   2. outputs Java source code (which is both recent (perhaps I might call it at 1.5 or later?) and easy to read), and which
   3. generates a properly encapsulated class.

Answer 1

Welcome to the vast world of Software Reuse, where you can choose among a vast array of components, all of which don't do quite what you want.

It is probably unrealistic to get a parser generator package that doesn't have "external dependencies". Almost any complex piece of software uses a library of special functions to support its purposes, and parser generators aren't really different. The distinction you make seems rather artificial, too. Imagine that a parser generator simply emitted the code for the external library, rather than simply referenced it. The amount of code you got, and how it was organized, would not be different. Why then would you object to the library version?

If you want parser generators that are not incomplete, I suggest you stick with mature ones. ANTLR and JavaCC in the Java world have quite long and successful track records.

If you insist you still don't want such things, you can always hand-code a recursive descent parser. This is especially effective for "simple" languages, such as yours appears to be. [What you'll discover is that you end up coding your own support library, although it doesn't have to be very big.]

Answer 2

As @Ira said, a generated parser will at least depend on a runtime that makes generic parsing options easy to invoke. The alternative would be to copy the exact same runtime code into each generated parser.

That said, I think JavaCC has the least runtime requirements: a CharStream class that you can copy from it's library.

Unfortunately, readability of generated parsers is inversely proportional to the features of the runtime. The less runtime, the lower the level, and less readability.

Given the limited scope of the Java parsing you require, you might want to analyze if what you need is achievable with just a regexp library.