Lambdafication (was Re: Default methods in JFX-8)
Danno Ferrin
danno.ferrin at shemnon.com
Sun Oct 6 16:58:32 PDT 2013
What are the metrics? Lines of code saved, size of jar, number of
generated classes, runtime performance?
On Sun, Oct 6, 2013 at 8:58 AM, Sven Reimers <sven.reimers at gmail.com> wrote:
> Ok. So here are the results of trying to add lambda and diamond to the
> controls module:
>
> 1. A lot of generics and typing to be fixed (esp. in tests). Seems you can
> get some anonymous inner classes type checked by the compiler, but not the
> lambda equivalent.. very interesting.
>
> 2. 279 Files modified (including tests)
>
> 3. A lot of the automatic replacements could probably be nicer e.g.
>
> ft.setOnFinished(new EventHandler<ActionEvent>() {
> @Override public void handle(ActionEvent
> actionEvent) {
> getChildren().remove(tm.textNode);
> }
> });
>
> was replaced to:
>
> ft.setOnFinished((ActionEvent actionEvent) -> {
> getChildren().remove(tm.textNode);
> });
>
>
This is actually better for the jfx78 backport, merging the lines would
create more false diffs when the only change is lambdafication.
> most unobtrusive code probably:
>
> ft.setOnFinished((actionEvent) -> getChildren().remove(tm.textNode));
>
> 4. A lot of illegal forward reference errors - these were result of missing
> this in the automatic transformation from anonymous inner to lambdas (seems
> the rules are not identical - you have to add "this." as prefix if using
> lambdas - not sure this is the expected way it should work)
>
> 5. Should we enable more -Xlint warnings in OpenJFX build?
>
> 6. Any chances anything of this can still go in 8 (e.g. get rid of warnings
>
> 7. Probably more things I just can't think of at the moment...
>
> How to take this forward? If there is interest in the change I could make
> available...
>
> Comments? Ideas?
>
> -Sven
>
>
>
> On Fri, Oct 4, 2013 at 2:19 PM, Sven Reimers <sven.reimers at gmail.com>
> wrote:
>
> > Oh and btw - would you go for lambda with or without additional type info
> > before parameter name?
> >
> > -Sven
> >
> >
> > On Fri, Oct 4, 2013 at 2:05 PM, Sven Reimers <sven.reimers at gmail.com
> >wrote:
> >
> >> Ok. Here you go...
> >>
> >> I just did an inspection run for the controls module and my IDE came up
> >> with (drum roll) 888 possible lambda conversions..
> >>
> >> Looking through them I discovered that usage of <> (aka diamond syntax)
> >> is not used (or at least not used a lot) in at least the controls
> >> modules. My IDE showed me 1171 occurrences.
> >>
> >> Is there a good reason not to use diamonds?
> >>
> >> Will now try to apply all those changes and figure out if this still
> >> builds... up next: go through the other modules...
> >>
> >> -Sven
> >>
> >>
> >> On Fri, Oct 4, 2013 at 1:35 AM, Richard Bair <richard.bair at oracle.com
> >wrote:
> >>
> >>> Brian was telling me at J1 that whether parallel gets you performance
> or
> >>> not depends on the size of the collection and the complexity of the
> work to
> >>> perform. There is definitely a point at which parallel helps -- and a
> point
> >>> at which it hurts.
> >>>
> >>> Richard
> >>>
> >>> On Oct 3, 2013, at 3:33 PM, Hervé Girod <herve.girod at gmail.com> wrote:
> >>>
> >>> > Here is a nice example, taking advantage of the ease of going
> >>> parallel. Apparently the performance without parallel will also further
> >>> improve.
> >>>
> http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/
> >>> >
> >>> > Hervé
> >>> >
> >>> > Sent from my iPad
> >>> >
> >>> >> On 4 oct. 2013, at 00:20, David Grieve <david.grieve at oracle.com>
> >>> wrote:
> >>> >>
> >>> >> And what about Stream? I like the declarative code that comes from
> >>> using Stream and I can see places in the code where Stream could be
> used,
> >>> but I wonder about its performance relative to iterators and/or
> enhanced
> >>> for loops.
> >>> >>
> >>> >> On Oct 3, 2013, at 4:45 PM, Richard Bair <richard.bair at oracle.com>
> >>> wrote:
> >>> >>
> >>> >>>> Hello, OpenJFX Community.
> >>> >>>>
> >>> >>>> There's a question about using Java 8 features in FX.
> >>> >>>>
> >>> >>>> I've been working on the support for InputMethods in JFXPanel
> which
> >>> is an important feature for many users who speak hieroglyphic
> languages.
> >>> >>>> The issue is tracked under:
> >>> https://javafx-jira.kenai.com/browse/RT-13248
> >>> >>>>
> >>> >>>> In order to have a high-quality support we need to change
> >>> javafx.scene.input.InputMethodRequests interface and introduce 3 new
> >>> methods. This is not needed for pure FX applications right now, but
> >>> absolutely required for InputMethods in the JFXPanel. However, the
> >>> interface is public and it was present since FX2.0, so changing it
> would
> >>> become a breaking change. So the only way to avoid the problem is
> using the
> >>> default methods. Those would return some stub values, the JDK is OK
> with
> >>> that, as it would not crash or throw exceptions, but text composition
> would
> >>> not work correctly.
> >>> >>>>
> >>> >>>> I know that we want to avoid using the Java 8 features in the
> >>> JFX-8, so I wanted to ask - is it OK to use the default methods here?
> >>> >>>>
> >>> >>>>
> >>> >>>> If you are staying away from JDK8 features for the JFX78 backport,
> >>> don't worry. There are more issues with new JDK8 APIs than with the
> new
> >>> language features.
> >>> >>>>
> >>> >>>> For example there were default methods put into some collections
> >>> classes that we solved by pushing them down to the first implements.
> But
> >>> the Date and Time picker depends on the new time package. The threeten
> >>> backport won't be updated until after 8 ships, so that has been
> removed so
> >>> far.
> >>> >>>>
> >>> >>>> I'de be interested to know what a wholesale lamdaization would
> >>> result in speed wise and code size wise (both source and compiled).
> From
> >>> what I can tell the IDEs can lambda and de-lambda fairly easily, so it
> jsut
> >>> makes the backport more of a busy work proposition. If there were
> >>> performance gains it would also make a great front page story in the
> next
> >>> java magazine or a case study..
> >>> >>>
> >>> >>> After having used Lambda's for JavaOne, I'd love to make the
> >>> conversion, even if in the end the performance was the same, because
> the
> >>> savings in noise in the Java files is so big. At one time I just took
> the
> >>> concurrent classes and lambda-ized them to measure the impact on those
> >>> classes. You could maybe pick a package and just lambda-ize that one
> >>> package and see what happens in terms of size reduction. We might see:
> >>> >>>
> >>> >>> + A reduction in the overall class size (not pack-200'd)
> >>> >>> - An increase in startup time (have to spin up synthetic classes
> >>> created at usage time)
> >>> >>> +/- And increase or decrease in performance
> >>> >>> + A decrease in source code
> >>> >>>
> >>> >>> It would be interesting to get some data for these points and see
> >>> what effect lambda's have. Especially if an IDE can just do it in bulk…
> >>> >>>
> >>> >>> Richard
> >>> >>
> >>>
> >>>
> >>
> >>
> >> --
> >> Sven Reimers
> >>
> >> * Senior Expert Software Architect
> >> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> >> * Community Leader NetBeans: http://community.java.net/netbeans
> >> Desktop Java:
> >> http://community.java.net/javadesktop
> >> * Duke's Choice Award Winner 2009
> >> * Blog: http://nbguru.blogspot.com
> >>
> >> * XING: https://www.xing.com/profile/Sven_Reimers8
> >> * LinkedIn: http://www.linkedin.com/in/svenreimers
> >>
> >> Join the NetBeans Groups:
> >> * XING: http://www.xing.com/group-20148.82db20
> >> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
> >> * LinkedIn: http://www.linkedin.com/groups?gid=1860468
> >> http://www.linkedin.com/groups?gid=107402
> >> http://www.linkedin.com/groups?gid=1684717
> >> * Oracle: https://mix.oracle.com/groups/18497
> >>
> >
> >
> >
> > --
> > Sven Reimers
> >
> > * Senior Expert Software Architect
> > * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> > * Community Leader NetBeans: http://community.java.net/netbeans
> > Desktop Java:
> > http://community.java.net/javadesktop
> > * Duke's Choice Award Winner 2009
> > * Blog: http://nbguru.blogspot.com
> >
> > * XING: https://www.xing.com/profile/Sven_Reimers8
> > * LinkedIn: http://www.linkedin.com/in/svenreimers
> >
> > Join the NetBeans Groups:
> > * XING: http://www.xing.com/group-20148.82db20
> > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
> > * LinkedIn: http://www.linkedin.com/groups?gid=1860468
> > http://www.linkedin.com/groups?gid=107402
> > http://www.linkedin.com/groups?gid=1684717
> > * Oracle: https://mix.oracle.com/groups/18497
> >
>
>
>
> --
> Sven Reimers
>
> * Senior Expert Software Architect
> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> * Community Leader NetBeans: http://community.java.net/netbeans
> Desktop Java:
> http://community.java.net/javadesktop
> * Duke's Choice Award Winner 2009
> * Blog: http://nbguru.blogspot.com
>
> * XING: https://www.xing.com/profile/Sven_Reimers8
> * LinkedIn: http://www.linkedin.com/in/svenreimers
>
> Join the NetBeans Groups:
> * XING: http://www.xing.com/group-20148.82db20
> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
> * LinkedIn: http://www.linkedin.com/groups?gid=1860468
> http://www.linkedin.com/groups?gid=107402
> http://www.linkedin.com/groups?gid=1684717
> * Oracle: https://mix.oracle.com/groups/18497
>
More information about the openjfx-dev
mailing list