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

[Richard Bair]

> 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