Lambdafication (was Re: Default methods in JFX-8)

Kevin Rushforth kevin.rushforth at oracle.com
Mon Oct 7 08:17:27 PDT 2013


I was just speaking about removing the warnings. Richard and Jonathan 
should chime in as to whether they are OK doing the lambda-fication in 
FX 8 (and about how they want to see the review done).

Please base any change on 8/graphics/rt

Thanks!

-- Kevin


Sven Reimers wrote:
> Ok. So I will file a P4 saying 
>
>
>   Lambdafication for Controls
>
> and send the diff to Richard/Kevin/Jonathan to be attached..
>
> should I base the change on b110 (master)?
>
> I could create a public bitbucket branch based on master and add my 
> changes there - better idea?
>
> What approach is most simple for review?
>
> Should I split test and library code changes?
>
> -Sven
>
> P.S. Shall I try to get this done as well for other modules? Which 
> would be preferred? (Just in case I have some more time to spend)
>
>
>
> On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>>     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
>
>     We have 2 weeks where we can still accept P4-P5 bugs into FX 8,
>     and getting rid of warnings would be a P4 bug. I guess it depends
>     on how intrusive the changes are and whether someone has time to
>     review it in the next two weeks.
>
>     -- Kevin
>
>
>
>
>     Sven Reimers 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);
>>     });
>>
>>     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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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