'byfile' compilation policy

[Liam Miller-Cushon]

On Thu, Apr 28, 2016 at 1:55 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Liam,
> the approach you put forward seems sensible; one alternate approach would
> be to let the entire compilation unit through until Gen if a dependency is
> encountered rather than stopping at desugar - but I assume that's what you
> said it's problematic because of cycles?
>

Right, the repro in my original message is an example of that. The
compilation units are: [One, Two] and [Three, Four], and the superclass
dependencies are: One -> Three, Four -> Two. So we can linearize the
classes to group by compilation unit, or so the superclasses are
encountered first, but not both.


> A meta-question: is it still worthwhile to have separate compilation
> policies? I see that at least two of them (ATTR_ONLY and CHECK_ONLY) can
> probably be replaced by other options (i.e. -XDshouldStop) - are there
> significant use cases out there relying on either byfile or simple? Given
> that, as it has been observed, javac will need to bypass the compilation
> policy anyway to guarantee the correctness of the generated code (i.e. that
> supertypes are desugared before subtypes) - can a client really blindly
> rely on the assumption that a compilation policy does what it says on the
> tin?


Consolidating the existing policies sounds like a good idea to me. I
haven't seen any uses of ATTR_ONLY or CHECK_ONLY. Using bytodo isn't great
for our purposes for the reasons Eddie described. In a previous thread [1]
it was mentioned that byfile was originally supposed to become the default.
Maybe it's time to consider replacing bytodo?

[1]
http://mail.openjdk.java.net/pipermail/compiler-dev/2015-August/009748.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160428/5542d539/attachment.html>