javac's tree API is equally unfit for IDEs editing/debugging which JEP 236
should help with. Which I presume is why NetBeans has its own javac fork
http://hg.netbeans.org/main/nb-javac-jdk8/
The JEP 236 Tree API is only good for abstract code analysis. It's not good
for tools that preserve most of the text as-is (say, a refactoring tool).
--emi
On Thu, Aug 4, 2016 at 8:11 AM, Sundararajan Athijegannathan <
sundararajan.athijegannat...@oracle.com> wrote:
> hmm.. not sure if Abstract syntax tree Parser API should provide offsets
> of "(", "}" etc. This API is modeled after javac's tree API - I don't
> think even that goes to that level of representation of the source code...
>
> -Sundar
>
>
> On 8/3/2016 2:38 PM, Emilian Bold wrote:
> > Hello,
> >
> > Since JEP 236 is designed to help with editing I believe the Tree API
> > should provide more offsets info about the whole statement.
> >
> > For example SwitchTree covers the switch statement:
> >
> > switch ( expression ) {
> > cases
> > }
> >
> > but it is impossible to determine the offsets of the curly braces or of
> the
> > round brackets.
> >
> > The closing curly brace is clearly located at SwitchTree.getEndPosition.
> >
> > But the first curly brace has an unknown offset somewhere between
> > SwitchTree.getExpression(). getEndPosition() + 1 and the getStartPosition
> > of the 1st CaseTree.
> >
> > Obviously exact offsets are necessary to provide matching brace
> > highlighting or code folding for the switch expression in an editor.
> >
> > Ideally SwitchTree would have contained a (Switch)BlockTree which in turn
> > would have contained the list of CaseTree-s.
> >
> > For the round brackets, SwitchTree.getExpression() could have returned
> > a ParenthesizedTree instead.
> >
> > PS: I wonder, would it be possible to guarantee that there is a way to
> > re-generate the exact input string based on the (CompilationUnit)Tree?
> > Because this is what seems necessary for an editor or for
> > minimally-invasive source-code processing tools.
> >
> > --emi
>
>
