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.]