Lambdafication (was Re: Default methods in JFX-8)
Sven Reimers
sven.reimers at gmail.com
Mon Oct 7 14:42:54 PDT 2013
Done...
https://bitbucket.org/sreimers/openjfx-8-lambdafication
Have fun
-Sven
On Mon, Oct 7, 2013 at 10:42 PM, Sven Reimers <sven.reimers at gmail.com>wrote:
> Ok jfxrt.jar sizes build from openjfx:
>
> 8165779 -> 7736259 bytes
>
> Will try to get this into a fork on github so you all can play with the
> actual state...
>
> -Sven
>
>
> On Mon, Oct 7, 2013 at 10:32 PM, Sven Reimers <sven.reimers at gmail.com>wrote:
>
>> First batch of statistics (controls submodule so far)
>>
>> 1630 vs 996 class in controls (my actual state on disk, YMMV)
>>
>> More statistics to follow...
>>
>> -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
>>
>
>
>
> --
> 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