Redundant bridge methods in nested classes

[Liam Miller-Cushon]

Interesting, thanks Maurizio.

On Wed, Jul 29, 2015 at 4:31 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> the biggest problem of the current code is that the bridge analysis
> depends on the members that were physically present on the superclasses;
> meaning that your analysis is chronically dependent on compilation order
> issues.
>

As long as the hierarchy is well formed, is it possible to enforce that
superclasses and interfaces (possibly including enclosing classes) are
always translated before the current class? I suppose there are some cycles
that would be tricky to get right: `class C<T extends C.N> { static class N
extends C {} }`. If that was possible, though, the implementation could
assert that classes are never translated recursively, and catch issues like
the one I noticed.


> In JDK 8 we had a similar issue when we implemented the logic for
> generating the set of bridges required by a lambda/method reference; as I
> was very aware of the compilation order issues, we designed an algorithm
> that was capable of 'simulating' the bridge presence in a given class,
> simply by looking at overriding properties between methods. This solution
> is, I believe, far superior, and should be preferred to the current
> approach which, in fact, adds a lot of convolutedness to the entire
> compiler pipeline, as it forces superclasses to be translated before
> subclasses (hint hint - what about superinterfaces???).


That does sound way nicer. Did you consider switching the regular bridge
implementation over to use the new algorithm?

I'm trying to grok functionalInterfaceBridges. Is the presence of bridges
only simulated for classes that will be translated in the current
compilation? The implementation appears to deal with classes completed from
class files that are missing bridges (maybe because they were compiled by
another compiler, or javac <= 7?).

Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150730/44c11429/attachment.html>