Default methods in JFX-8

[Petr Pchelko]

Hello, Richard.

Thank you.

>  What code needs to call these new methods?

These are used in the JFXPanel to provide the needed information to the AWT/Swing, so that it could properly position the text composition window and track what is going on with the text.

> I don't know enough about the domain to know what other options you have, besides adding InputMethodRequests2 or whatever and having to do an instanceof test and cast. But that might actually be the better way to handle this situation
We could add some internal extension of the interface and use instanceof checks. It would be done in a single place and would not make a lot of harm. 
The only problem with this approach is that third-party text-input component would not be able to support IM inside the JFXPanel.

So, if you think JFXPanel does not worth adding new public API which is not required by FX itself I could try to reimplement the feature using some internal extension.

With best regards. Petr.

On Oct 4, 2013, at 12:00 AM, Richard Bair <richard.bair at oracle.com> wrote:

> I don't think returning 0 from getInsertPositionOffset() or getCommittedTextLength() is correct, because 0 is a legitimate value to return from those methods when they're working correctly. How do you distinguish between a legitimate value of 0, and an illegitimate one? It seems rather that the defaults could be -1 and null, and that code calling these methods would understand these values to mean "not implemented" and deal accordingly.
> 
> I'm thinking here of 3rd party code that calls methods on InputMethodRequest. Initially of course they won't be calling these new methods, so no change in behavior for them. However once they start calling these methods, they may need to be able to distinguish between an implementor that fully implements InputMethodRequests, and one that doesn't.
> 
> It seems like the successful uses of default methods have been when adding some method that could be implemented in terms of the existing API on the interface, such that it fits seamlessly into the existing interface as though it were always there, and where an implementor could create a more efficient implementation of the method, but doesn't really have to. In this case it seems like these methods really won't fit well into the existing interface. I don't know enough about the domain to know what other options you have, besides adding InputMethodRequests2 or whatever and having to do an instanceof test and cast. But that might actually be the better way to handle this situation. What code needs to call these new methods?
> 
> Richard
> 
> On Oct 3, 2013, at 11:24 AM, 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? 
>> 
>> Here's the questioned API:
>> 
>> /**
>>  * Returns the offset of the return position in the committed text contained in the text editing node
>>  */
>> default int getInsertPositionOffset() { return 0;}
>> 
>> /**
>>  * Gets the entire text contained in the text editing node except the uncommitted text.
>>  */
>> default String getCommitedText(int begin, int end) {return "";}
>> 
>> /**
>>  * Gets the length of the entire text contained in the text editing node
>>  */
>> default int getCommitedTextLength() {return 0;}
>> 
>> Thank you.
>> With best regards. Petr.
>> 
>