Default methods in JFX-8
herve.girod at gmail.com
Thu Oct 3 13:48:33 PDT 2013
There are already obvious and potentially huge performance gain when using parallel, even now.
Sent from my iPhone
> On 3 oct. 2013, at 22:39, Danno Ferrin <danno.ferrin at shemnon.com> wrote:
> On Thu, Oct 3, 2013 at 12:24 PM, Petr Pchelko <petr.pchelko 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
> 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..
More information about the openjfx-dev