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 <[email protected] <mailto:[email protected]>> 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 <[email protected]> 
<mailto:[email protected]> 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 <[email protected]> 
<mailto:[email protected]>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 <[email protected]> 
<mailto:[email protected]>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 <[email protected]> 
<mailto:[email protected]> 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 <[email protected]> 
<mailto:[email protected]>
    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 <[email protected]> 
<mailto:[email protected]>
    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

Reply via email to