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

Sven Reimers sven.reimers at
Thu Oct 3 14:16:14 PDT 2013

You can do this using NetBeans 7.4 RC 2 - select Inspect and Transform and
go hunting for "Use Lambda"...

I tried it on a legacy codebase and it worked out of the box without any


On Thu, Oct 3, 2013 at 10:45 PM, Richard Bair <richard.bair at>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:
> >
> > 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:
* Community Leader  NetBeans:
                              Desktop Java:
* Duke's Choice Award Winner 2009
* Blog:

* LinkedIn:

Join the NetBeans Groups:
* LinkedIn:
* Oracle:

More information about the openjfx-dev mailing list