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 problems. -Sven On Thu, Oct 3, 2013 at 10:45 PM, Richard Bair <[email protected]>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
