Javac supports different compilation policies: simple, by file, by todo.
There are subtle differences between them, and even bugs that can be
triggered in one but not in the other. Recently Liam asked several
question on compiler policies on compiler-dev:
http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010568.html
Now, the reason why Liam wants to use by file by default is that he
found some issues where there's a cyclic dependency in the
supertypes/inner classes relationships, so that JavaCompiler cannot
'linearize' the order in which classes are desugared in a correct way
(see JavaCompiler.desugar). We believe the right way to solve this issue
is to actually remove erasure from TransTypes, which will then keep
types in the AST (see below technical debt item).
Regardless of what we do for Liam's problem with cyclic hierarchies,
compiler policies seems a bit finicky, and I think it's wrong to expose
them as options. We should pick the policy we think it's best, and stick
with it. Otherwise I think that (as in this case) it becomes an
'attractive nuisance' that people might be tempted to use to mitigate
real bugs.
There are subtle differences between them, and even bugs that can be
triggered in one but not in the other. Recently Liam asked several
question on compiler policies on compiler-dev:
http://mail.openjdk.java.net/pipermail/compiler-dev/2016-December/010568.html
Now, the reason why Liam wants to use by file by default is that he
found some issues where there's a cyclic dependency in the
supertypes/inner classes relationships, so that JavaCompiler cannot
'linearize' the order in which classes are desugared in a correct way
(see JavaCompiler.desugar). We believe the right way to solve this issue
is to actually remove erasure from TransTypes, which will then keep
types in the AST (see below technical debt item).
Regardless of what we do for Liam's problem with cyclic hierarchies,
compiler policies seems a bit finicky, and I think it's wrong to expose
them as options. We should pick the policy we think it's best, and stick
with it. Otherwise I think that (as in this case) it becomes an
'attractive nuisance' that people might be tempted to use to mitigate
real bugs.