Program transformation systems for Java programs (that is, Java is the object language) usually operate on an abstract syntax representation of the Java source code. Java has no standardized or de facto standard for its abstract syntax.

Eclipse JDT Core 3.x

The JDT Core component of Eclipse provides a 'Java Document Model' in the package org.eclipse.jdt.core.dom. This API can be used for manipulating a structured Java source document.

• AST can be serialized. However, this is an unformatted String representation which is not guaranteed to be correct. The real formatter can only be applied to a String and the pretty-printer of the AST can only be applied if the original Java source has also been parsed by the Eclipse JDT Core parser
• The API looks attractive and feature-rich, but many of these features only work inside Eclipse. For example, resolving bindings outside of Eclipse is nearly impossible.

• Basic AST implementation is not required to be executed in an Eclipse plugin.
• Classes are written by hand and contain useful accessor methods.
• Representation is 'type-safe': it is not based on generic superclasses for storing nodes.

Eclipse JDT Core before 3.0 Milestone 8

The JDT Core component of Eclipse provides a 'Java Document Model' in the package org.eclipse.jdt.core.dom. This API can be used for manipulating a structured Java source document.

• An application of this AST must itself be an Eclipse plugin.It cannot be used from ordinary Java programs since an instance of the Eclipse Runtime is required. It is not dependent on the UI however.
• No proper pretty printing. toString methods can be used to produce Java concrete syntax, but these methods are intended for debugging only.

OpenJava

More on this soon ...

JavaCC/JRefactory

The JRefactory refactoring tool for Java uses an abstract syntax tree generated by JavaCC/JJTree. JRefactory contains a configurable pretty printer for this abstract syntax tree. Mike Atkinson has taken over the development from Chris Seguin and is working on the extensions of the j2sdk 1.5.

• AST is not really abstract. The presence of literals makes it feel more like a parse tree/CST.
• AST is not type safe. Generic superclasses are used to store 'nodes' and 'specials'
• AST feels very generated. The number of hand-written accessor methods is limited

• Configurable pretty printer

SableCC

SableCC is a compiler compiler producing Java. It generates strictly typed abstract syntax tree classes for the object language. There is a Java 1.4 grammar for SableCC, which therefore defines an abstract syntax for Java. As far as I know that is no pretty printer for this AST.

• No pretty printer available for the abstract syntax tree
• No facility to add user defined to the generated classes without making regeneration impossible

• Choose between the CST and AST representation in SableCC 3 (not yet implemented in the Java grammar although).
• Generates tree walkers.
• Representation is 'type-safe': it is not based on generic superclasses for storing nodes.

Stratego/XT and java-front

Stratego/XT's java-front defines the concrete syntax for Java in SDF and generates abstract syntax tree definitions from this concrete syntax definition. java-front contains a pretty-printer implemented in Stratego for this Java abstract syntax.

• ASTs are exchanged in the ATerm format, which is limited to ASCII characters
• Type safety is not enforced by the ATerm format. The meta language or the programmer is responsible for this.
• Tools are not implemented in Java. Requires a POSIX compatible operating system

• Lexical constructs like string and characters literals are structured
• Representation is abstract: syntactical details like literals are not present
• High quality pretty-printer
• Parser and pretty-printer support comment preservation
• Full support for 1.5
• Option to parse Java to an AST concisely represented in an XML document

Java Compiler API

A future goal of JSR 199: Java Compiler API is to standardize the structured representation of Java source code in an abstract syntax tree.

• It doesn't exist.

Maintainer

This page is maintained by Martin Bravenboer. This is Wiki, so you can contribute if you want to provide additional information. Of course you can also just send me your comments by e-mail.