deduplicating lambda methods

Vicente Romero vicente.romero at
Thu Mar 15 20:31:59 UTC 2018

Hi Liam,

overall looks good, some comments after eyeballing the patch:

- it seems like: map dedupedLambda, could be a set.
- TreeDiffer, consider the benefits / trade-offs of extending instead of implementing 
TreeVisitor. The code will change a bit and you will probably need to 
declare a boolean field for the result but you will have access to the 
subclasses of JCTree without casting and will be able to use the 
getTag() method in JCTree, in most cases being JCExpression the 
exception, to avoid most instanceof checks.
- symbols are unique so you can use == to test equality
- you don't need: Objects.equals(tree.isStatic(), that.isStatic()), to 
compare two booleans
- names are also unique so you can use == instead of 
Objects.equals(tree.getLabel(), that.getLabel())
- in general there are complete implementations for trees that can't 
appear inside the method's body, but I think that they were provided for 


On 03/15/2018 02:52 PM, Liam Miller-Cushon wrote:
> I uploaded a webrev with the current sketch:
> <>
> * Nothing here is intended to be final, I'm interested in feedback on 
> the direction and any suggestions for next steps.
> * It shows the approach used for ast comparison, including the lambda 
> parameter handling I described. The lambda parameter handling is 
> currently baked-in, but it could easily be refactored to allow the ast 
> diffing to be used in other contexts.
> * There is no handling of debug info yet.
> On Sun, Mar 4, 2018 at 7:59 PM Liam Miller-Cushon <cushon at 
> <mailto:cushon at>> wrote:
>     On Fri, Mar 2, 2018 at 8:01 PM, Vicente Romero
>     <vicente.romero at <mailto:vicente.romero at>> wrote:
>             1) How to identifying duplicates: I have a prototype that
>             runs during lambda desugaring and identifies duplicates by
>             diffing ASTs. Is that the best place for deduplication, or
>             it worth considering comparing generated code instead of ASTs?
>         are you doing an exact diff? I assume that we want: s -> s to
>         be equal to z -> z provided that the target is the same
>     Lambda parameters are currently handled as a special case. The
>     diff tests that the syntax for the two trees is the same, and that
>     the symbols associated with identifier and select nodes are
>     equivalent. It accepts symbols that correspond to the same
>     parameter in each of the associated lambda methods.
>     E.g. when diffing the lambda bodies for `s -> s` and `x -> x` it
>     sees that `s` and `x` are both the first parameter of their
>     enclosing lambdas.

More information about the amber-dev mailing list