Lambdafication (was Re: Default methods in JFX-8)
Danno Ferrin
danno.ferrin at shemnon.com
Mon Oct 7 13:31:06 PDT 2013
You can fork from here:
https://bitbucket.org/openjfxmirrors/openjfx-8-graphics-rt
It updates every 4 hours based on a cloudbees job.
On Mon, Oct 7, 2013 at 11:23 AM, Sven Reimers <sven.reimers at gmail.com>wrote:
> Ok.
>
> So Lamdafication after 8.
>
> Fixes for warnings still in for 8?
>
> Will try to get some more data out of my trial... and if this needs time a
> full OPenJFX-Lambda branch might be handy on bitbucket...
>
> Next nightshift...
>
> -Sven
>
>
> On Mon, Oct 7, 2013 at 6:24 PM, Richard Bair <richard.bair at oracle.com>wrote:
>
>> My thoughts exactly, which is why I'm grateful for Sven for trying it out
>> :-). I expect that Lambda would make a big reduction in static class count
>> (i.e.: class files), but not a major reduction in class count at runtime
>> (since dynamic classes are created for Lambdas). So a normal Jar should be
>> significantly smaller, while a Pack200 jar probably has little to no
>> difference. Execution speed should be the same. Startup might be faster or
>> slower, I'm not sure (but I would expect it to be negligible). If the jar
>> is significantly reduced in size, it might be useful for embedded which
>> doesn't use Pack200.
>>
>> But we need the data, because making the change at this point, otherwise
>> in a couple months when we get a 9 / 8u workspace opened we can start
>> putting the work in there (since in my mind there is no question but that
>> for 9 we need to complete lamdafication).
>>
>> Richard
>>
>> On Oct 7, 2013, at 8:19 AM, Danno Ferrin <danno.ferrin at shemnon.com>
>> wrote:
>>
>> > IntelliJ at least has a decent de-lamba assistant, not sure about
>> NetBeans
>> > since it isn't my daily driver. So I am not concerned about the
>> > backporting impact if (and this is the big if) there is demonstrable
>> > improvement in either jar size, execution speed, or runtime memory
>> impact.
>> > Ideally all three. Worth the hassle in that case. But if all we get
>> from
>> > this is busy work, then i would then question it's value.
>> >
>> >
>> > On Mon, Oct 7, 2013 at 8:21 AM, Tom Schindl <
>> tom.schindl at bestsolution.at>wrote:
>> >
>> >> ... I can't see any real improvement for using lambdas beside that you
>> >> killed off warnings which could be fixed otherwise as well.
>> >>
>> >> So I really don't get what it would help us beside making e.g. RoboVM
>> >> our sole chance to get FX on iOS harder to maintain.
>> >>
>> >> Tom
>> >>
>> >> On 07.10.13 16:16, 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>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>
>> <
>> >> 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>
>> <
>> >> 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>
>> >> <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> <
>> >> 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> <
>> >> 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> <
>> >> 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