Eclipse Community Forums: Java Development Tools (JDT) » what's the difference between public DOM AST and internal AST

Help

Home

Home » Language IDEs » Java Development Tools (JDT) » what's the difference between public DOM AST and internal AST

Show: Today's Messages :: Show Polls :: Message Navigator

what's the difference between public DOM AST and internal AST [message #840557]

Tue, 10 April 2012 08:28

Wooyoung Cho

Messages: 3
Registered: April 2012

Junior Member

Hi.
I have two questions.

1. I noticed that there are two ASTs in JDT: public and internal ASTs. Why there are two sets of ASTs. Is it because of internal AST can be changes in the future?

2. Public AST uses ASTNode.NodeList to represent a list of child nodes. And ASTNode.NodeList is just a list of ASTNodes. For example, Block.statements has ASTNode.NodeList type and it doesn't have the concrete type information of child nodes. I wonder why NodeList is used instead of type such as NodeList<Statement>?

Thanks.

Report message to a moderator

Re: what's the difference between public DOM AST and internal AST [message #840611 is a reply to message #840557]

Tue, 10 April 2012 09:48

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Quote:

1. I noticed that there are two ASTs in JDT: public and internal ASTs. Why there are two sets of ASTs. Is it because of internal AST can be changes in the future?

Both are developed with very different goals. The internal ast satisfies the needs of the compiler. The public DOM AST is designed for inspection and modification by client plug-ins. Decoupling the evolution of the compiler AST from public API is one reason for the separation. But it isn't even clear if it would be possible to create one AST that combines all properties of the two structures that we have.

Let me ask back: when working with the public AST is there anything you want to do for which this AST is not appropriate?

Quote:

2. Public AST uses ASTNode.NodeList to represent a list of child nodes. And ASTNode.NodeList is just a list of ASTNodes. For example, Block.statements has ASTNode.NodeList type and it doesn't have the concrete type information of child nodes. I wonder why NodeList is used instead of type such as NodeList<Statement>?

JDT/Core is (still) required to run on platforms < Java 5. Thus its implementation cannot (yet) use generics. Much to our own regret, actually Smile

best,
Stephan

Report message to a moderator

Re: what's the difference between public DOM AST and internal AST [message #840654 is a reply to message #840611]

Tue, 10 April 2012 10:45

Wooyoung Cho

Messages: 3
Registered: April 2012

Junior Member

I thought that the design of ASTNode.NodeList is intentional to support language extension(e.g. Java12 may introduce Block that can include non-statement ASTNode) without modifying type signature. But it's not. right?

I want to know what kinds of nodes can be located as children of a certain node so that I can iterate the child nodes and use them by casting. I realized that I can refer ASTNode.structuralPropertiesForType() of each node type to determine the actual types of child nodes. It looks like implementing reflection by hand. Is it right?

Report message to a moderator

Re: what's the difference between public DOM AST and internal AST [message #840667 is a reply to message #840654]

Tue, 10 April 2012 11:06

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Quote:

I want to know what kinds of nodes can be located as children of a certain node so that I can iterate the child nodes and use them by casting.

Just look at the javadoc, e.g.,

        /**
         * The body declarations (element type: {@link BodyDeclaration}).
         * Defaults to an empty list.
         * @since 2.0 (originally declared on {@link TypeDeclaration})
         */
        ASTNode.NodeList bodyDeclarations;

Here casting to BodyDeclaration is safe, for everything more specific you need runtime checks.

Quote:

I realized that I can refer ASTNode.structuralPropertiesForType() of each node type to determine the actual types of child nodes. It looks like implementing reflection by hand. Is it right?

Property descriptors are indeed a reflection-like mechanism.

best,
Stephan

Report message to a moderator