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.fer...@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.schi...@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.rushfo...@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.reim...@gmail.com> <
>> sven.reim...@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.reim...@gmail.com> <
>> sven.reim...@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.b...@oracle.com>
>> <richard.b...@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.gi...@gmail.com> <
>> herve.gi...@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.gri...@oracle.com> <
>> david.gri...@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.b...@oracle.com> <
>> richard.b...@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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
