JEP 190: Pluggable Static Analyzers

[Eric McCorkle]

On 01/29/14 02:59, Jeremy Manson wrote:

> The combination of the fact that no one else seems to build significant
> tooling on it (AFAICT), the fact that we've had to deal with a steady
> trickle of incompatibilities, and the fact that various desugarings /
> lowerings happen before the AST is built, have combined to make us think
> that javac isn't being taken seriously as a tooling API.  OTOH, javac
> has the benefit that it *is* the source of truth, it is easy to
> integrate analyses with compilation, and we don't have to worry about
> you guys screwing it up / abandoning it.

Given that this is a research JEP, I would prefer to think more in terms
of "what API's/features/etc would be useful to have", rather than the
current oddities of javac.  There is already a sizable amount of
refactoring being undertaken, so I think it would be more productive if
we don't focus on those aspects here.

> I would support a JEP that states clearly and decisively, "as of Java 9,
> we are treating javac seriously as a tooling API, and outstanding issues
> will be resolved".  If someone is committing time and resources to that,
> that's a good thing.  Perhaps I read too much into this JEP.  

That sort of statement is way beyond the scope of this JEP.  This is a
*research* JEP intended to investigate a number of possible directions
for exposing javac internals.  It is not a goal of this JEP to implement
an new feature, or an update to any existing feature.

> (There was a lot of talk in the JEP about type annotations, but, AFAICT,
> those aren't a major issue, and tools like the Checker Framework seem to
> do pretty well with what exists, plus -Xplugin.  OTOH, it's reasonably
> true that someone needs to build a non-researchy way of doing serious
> data and control flow analyses for Java; Soot is a pile of cruft at this
> point, and Wala has an immutable CFG, which makes certain kinds of
> things tricky.)

Type annotations provides a very flexible system for attaching
additional information to types.  One possible use of this might be to
provide a mechanism for extending the type system (though this is just a
possibility, and such a mechanism needs to be designed very carefully).

> 
> As for other solutions...  We are in a position where we would like to
> have a formatter built into our static tooling in the near term, so
> we're actively looking at other solutions (for formatting) now.  ecj and
> IntelliJ both have parsers that people use to build substantial amounts
> of tooling.  They even have existing formatters!  ecj seems to have a
> lot of legacy issues, but IntelliJ looks potentially promising.  We're
> looking into it.

I think these requests, while worth considering, aren't within the focus
of this JEP.  This JEP focuses on the middle stages of the compilation
pipeline, while these goals seem more focused on parsing.

> 
> Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140131/ae5d07ae/eric_mccorkle.vcf