RFR 8155674: Move javac towards a "by-file" compilation policy

[Liam Miller-Cushon]

What do you think about pursuing this as an interim fix? It solves a
problem we were seeing trying to analyze entire compilation units after
flow, and it's harder to observe whether by-file is followed correctly
after that. Or would you rather just wait for the ordering constraint to be
removed in 10?

On Sun, Dec 4, 2016 at 2:11 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Also don't forget that the cycle problem is temporary  - as discussed in
> that thread, the fix here is to actually get rid of erasure (which is
> something we did already in an experimental patch in Valhalla) which then
> removes the ordering problems with supertypes/subtypes. We plan to do
> further experiments with this in the Valhalla repo and move this code to 10
> when ready.
>
> Maurizio
>
> On 02/12/16 02:18, Liam Miller-Cushon wrote:
>
> On Thu, Dec 1, 2016 at 6:06 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> Does this address the potential problem with cycles that you mentioned in
>> the original email?
>>
>
> Not fully. It improves the current behaviour by ensuring files always go
> through attr and flow as a unit, but classes may still be desugared
> separately from their compilation unit.
>
> One of the test cases has compilation units [One, Two] and [Three, Four],
> where Two extends Four, and Three extends One. There's no way to linearize
> that so supertypes are desugared first and files are desugared as a unit.
>
> Are there still plans to remove the ordering constraint in TransTypes?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161207/97ddba2c/attachment.html>