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

Kevin Rushforth kevin.rushforth at oracle.com
Mon Oct 7 04:26:44 PDT 2013


>
> 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> 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
>>
>>     
>
>
>
>   


More information about the openjfx-dev mailing list