Такие инструменты в основном должны реализовывать интерфейс компилятора, по крайней мере, для подмножества языка. Самой простой отправной точкой часто является адаптация существующего внешнего интерфейса компилятора, поэтому вам определенно следует начать с просмотра компилятора вашего клиента.Если вам повезет, в нем будет четкое разделение между интерфейсом и сервером, и вы сможете использовать его как есть и использовать AST или любой другой IR, который создает интерфейс, для дополнительного анализа.
Вы же не хотите писать все это с нуля.
Смотрите DMS Software Reengineeering Toolkit. Он содержит обобщенные механизмы компилятора для синтаксического анализа, построения AST, построения таблиц символов, построения/обхода графов потока управления и потока данных и деревьев вызовов.
DMS можно получить с полным фронт-эндом Java, который строит AST, таблицы символов и анализирует потоки данных. DMS прекрасно справляется с языковыми диалектами, поэтому модифицировать этот фронт-энд под Java-вариант языка вашего клиента и при этом получить все эти механизмы анализа должно быть максимально просто.
Что насчет PMD? Я использую PMD уже много лет, но никогда раньше не вникал в его внутреннюю работу.
PMD можно расширить, написав собственный парсер языка, что делается путем предоставления реализаций следующего в JAR по пути класса.
net.sourceforge.pmd.cpd.Language
net.sourceforge.pmd.cpd.Tokenizer
http://pmd.sourceforge.net/cpd-parser-howto.html
Затем, используя PMD конструктор правил, я могу определить правила из полученного AST.
Мне нравится в PMD то, что это широко признанный инструмент анализа кода в Java-пространстве, поэтому он имеет много сторонней поддержки. Например, плагин для Eclipse, плагин для Hudson CI и т.д. и т.п.