<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 01/28/2014 01:01 PM, Jeremy Manson
wrote:<br>
</div>
<blockquote
cite="mid:CAPYFHW2-2JTyjg6G9Z=Z9f7i26G5zqqn0cuUPR+W1DYgsJqqHg@mail.gmail.com"
type="cite">
<div dir="ltr">Our experience is that the various tree APIs aren't
quite enough for a couple of reasons:
<div><br>
</div>
<div>- Because of actions that are taken during parsing, the AST
can't easily be used to map back to the original code.
 Limitations range from things as simple as concatenating
strings during parsing to problems as serious as having no
access to the original source / comments. Â This makes it hard
to do things like write formatters.</div>
</div>
</blockquote>
<br>
We are aware of issues where the source tree does not directly
correspond to the elements in the source code. The obvious main
example is enum member declarations, which are desugared right in
the parser. uugh. We are working to address those issues. Comments
are more tricky. I doubt we would ever want to see comments
faithfully rendered in the AST (it is a syntax tree after all) --
and the recommendation for utilities like formatters is to use the
source positions (which are intended to be accurate) to map back to
the original source text so that you can re-examine the text in the
vicinity. <br>
<br>
<br>
<blockquote
cite="mid:CAPYFHW2-2JTyjg6G9Z=Z9f7i26G5zqqn0cuUPR+W1DYgsJqqHg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>- The tree API is relatively stable, but some of the
ancillary APIs change from revision to revision. Â We've had to
use reflection to access, for example, the logging API, as it
changes from version to version (if we want to support more
than one version at a time). Â ISTR having a problem with the
file manager API in the javac6->7 transition, too (although
I can't remember the details).</div>
</div>
</blockquote>
<br>
There were some changes in the processing Filer API needed to fix
incorrect behavior that I remember.<br>
<br>
<blockquote
cite="mid:CAPYFHW2-2JTyjg6G9Z=Z9f7i26G5zqqn0cuUPR+W1DYgsJqqHg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>In the few years we've been writing tools on top of javac,
we've found that a steady stream of missing features and
changed APIs have made our lives slightly, but consistently,
more complicated (or simply prevented us from implementing
various features). Most of the issues we've seen are pretty
fixable, though.</div>
</div>
</blockquote>
<br>
I would hope that while there may be some issues that made your life
more complicated, you still found it less complicated overall to use
javac instead of any other solution.  And you are right, many of
the issues are fixable: it just comes down to time and resources.<br>
<br>
-- Jon<br>
<br>
<blockquote
cite="mid:CAPYFHW2-2JTyjg6G9Z=Z9f7i26G5zqqn0cuUPR+W1DYgsJqqHg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Jeremy</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Jan 28, 2014 at 11:31 AM,
Jonathan Gibbons <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jonathan.gibbons@oracle.com" target="_blank">jonathan.gibbons@oracle.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb">
<div class="h5">On 01/28/2014 11:11 AM, Eric McCorkle
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 01/28/14 03:49, Florian Weimer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 01/28/2014 01:52 AM, Jonathan Gibbons wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Why is JEP 190 different from the support already
in javac for pluggable<br>
static analyzers, such as provided by -Xplugin?<br>
</blockquote>
The JSR 269 interface does not provide access to
expressions and method<br>
bodies. Â It happens that through this interface,
javac internals which<br>
provide this information are available after casting
to internal javac<br>
classes. Â However, this is not a supported
interface, and the internal<br>
javac data structures are not directly suited to
implementing analysis<br>
passes.<br>
<br>
</blockquote>
An eventual goal of the system envisioned by JEP 190
is to allow<br>
analysis tools to operate on javac's trees as opposed
to source or<br>
bytecode (as is common now). Â Of course, there are
quite a few<br>
intermediate steps that have to be taken to realize
that goal.<br>
</blockquote>
<br>
</div>
</div>
You can easily do this in JDK 8 with -Xplugin, using the
com.sun.source API. Â com.sun.source is a public supported
API. Are you suggesting that is not enough, and that you
want to start investigating a standard javax.* AST API?<br>
<br>
The one piece that is missing in the -Xplugin world is easy
access to the proto-bytecodes from a plugin.<br>
<br>
-- Jon<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>