Hacker News new | ask | show | jobs
by jbangert 3515 days ago
Error-prone is somewhat tied to a specific version of the Java compiler -- so you need Javac 8, but you can set --source to an older version of the language. If the newer Javac does not emit bytecode that works with your runtime, you can run two compiles (one error-prone for the errors, one production compile with whatever compiler you need).
2 comments
needusername 3515 days ago
Haven't we learnt several times in the past that this is a bad idea? Eg. with Android or GAE/J. This is going to require a lot of effort for every upcoming Java release delaying support for a long time, again see Android or GAE/J. It also makes integration with Eclipse difficult at best.
link
Seol 3514 days ago
It depends on what you mean by "bad idea". You've got three choices, basically: analyse source, analyse the AST, or analyse bytecode. There are advantages and disadvantages of each approach, but for what Google's trying to do - allow people to write their own checks - there are clear advantages to analysing the AST.

I've written checks in both error-prone and Findbugs and error-prone is simply more natural. Part of that is the Findbugs API, for want of a better word, is godawful, but the AST is simply the best representation of the program for analysis.

If you're going to analyse the AST, you then have a further two choices: build your own AST, or hook into the compiler. Building it yourself is dangerous here: firstly, it's repeating a lot of work that's already been done, but more importantly you want to be absolutely sure that what you're analysing is what you're actually building. Either way you have to do updates when the language changes, as any static analysis tool needs to.

Are there costs to this decision? Yep. Is it going to be the right tool for every job? Nope. But that doesn't mean that these decisions don't have reasoning behind them, and compelling reasons to go this way.

link
needusername 3514 days ago
I am not questioning the AST approach. I'm questioning the approach of hooking into JDK internals and using JDK internals as an interface for custom check implementations.

Google has done similar things several times in the past (GWT, GAE/J, Android) and every time updates to the latest Java required a lot of effort, were therefore late and eventually abandoned.

link
Afty 3514 days ago
We package a specific revision of javac and use it for Error Prone. Currently this is a ~year old version of javac 9, which means that:

1) You have to execute your compiler on JDK >=8.

2) You cannot target bytecode <= Java 5.

link