Questions should go to the users mailing list, but I'll assume that you say this is a bug.

Did you actually try "Tokenizer.TOKEN_TYPE_PARAMETER"? Neither opennlp.uima.tokenize.AbstractTokenizer nor opennlp.uima.tokenize.Tokenizer declare such a constant. They refer to the constants defined in UimaUtil. If you try it, you should notice that you get a compiler error.

No, I haven't tested it. It just looks unreasonable to have parameters prefixed UimaUtil for an AE named Tokenizer. It's confusing in an introduction. It also looks like one of those copy-and-paste errors I sometimes make.

I'm afraid, it is the way that the OpenNLP UIMA components are implemented. I'll mark this bug here as invalid.

There's another trade-off / fine-line-to-walk possible here, informed by the principle of least surprise . So, when you document some example, which (to new readers) seems confusing, because it's "required" by the particular things in your example, you could choose to acknowledge the potential surprise by adding a short comment - something like "you might be surprised that these constants are in the UimaUtil class/interface, rather than the Tokenizer class/interface, but that's where those components define them!

The downside of adding things like this is that your documentation gets longer. And today's reader of documentation is probably impatient, and somewhat annoyed by longer docs.

There's things you can do with formatting to mitigate this kind of thing, like making it a "note", perhaps in slightly smaller font, so it's subordinate to the main "flow", visually.

Good point, Marshall Schor.

Reopening as a reminder to add an explanatory note to the documentation.