Seol

One way to do this is to find a better job.

Another way to do it is to put more effort into improving the quality of your current team. In the long run, that's a skill you're gonna need.

I particularly like the "anti-priorities" section. You can't optimise for everything, and it's refreshing to see someone be upfront about the things which they're prepared to let be sub-optimal.

Of course, it's important to read that section as "what I don't prioritise", not "what you shouldn't prioritise".

The interesting thing is that the "obvious correct" behaviour would require the precedence of the + operator to depend on the types of the operands - which is obviously impossible if it's done at the parse stage...

Strong v weak typing isn't an absolute categorisation, it's a spectrum. There aren't many places Java will automatically coerce types, and the ones that do exist are narrow (numeric promotion, string concatenation, and I can't think of any others).

But the problem with Hollywood accounting isn't that distributors are unable to transparently share financial details. It's that they've worked very hard to find ways to obfuscate it, so as to reap higher profits.

What incentive do the distributors - your customers, and gatekeepers to using this approach - have to adopt it?

Surely, this is a technical solution to a non-technical problem?

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.

The distinction I was trying to make was one between where in the toolchain it lives: error-prone is part of compilation, whereas Findbugs is after-the-fact.

Error-prone is a compiler plugin _mechanism_ - once you have an error-prone compiler, the checks are arguments to the compiler just like APT annotation processors are.

It's built on a standard API - the JavaCompiler mechanism built into the Java SDK - but yes, the code does have further dependencies on com.sun packages. This is a little confusing because why expose the compiler for invocation and extension when extensions have to rely on unsupported code?

So, yes, there are ways where the distinction is important, but they're orthogonal to the point I was trying to make.

Technically, it's not a compiler plugin - it actually replaces javac by extending JavaCompiler, wrapping it and applying additional verifications without altering the output. Effectively it's introducing its own API for compiler plugins, with those being the checks, very much akin to APT.

See https://github.com/google/error-prone/blob/master/core/src/m... for the entry-point.

I'm very close to getting out of my depth here though :)

Also, error-prone works in a fundamentally different way to FindBugs: error-prone is a compiler plugin, whereas Findbugs is an after-the-fact static analyser. This means, for example, you can include dependencies on the codebase you're analysing in your findbugs checks, but not in error-prone.

This turns out to be really quite relevant if you're building domain-specific static analysis checks, as opposed to just running standard analyses.