Default methods in JFX-8

[Hervé Girod]

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
> 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..