New API to read Caps-Lock and Num-Lock state

[Frederic Thevenet]

Hi,

 From the perspective of the application developer, I think throwing a 
runtime exception if the key does not exists on a given platform is 
potentially risky, as the API provided no hints that a given key might 
not exists an other platforms, and this oversight will only manifest 
itself at runtime, on said platform.

With the other two proposed solution (three-state return and Checked 
exception) the API itself reminds its would be consumer that they should 
consider a case where the operation is invalid.

I'm personally not keen on checked exceptions in such a scenario either, 
as it would require an extra API to check for the existence of a given 
key on the current platform, or condemn developers to implement 
conditional logic via exception catching (or require developer to know 
what specific keys exists on what platform before-hand to do the check).

Given all that, my personal preference would go to a three state return 
solution.

On that topic, is there anything that would preclude the use of an 
Optional<Boolean> to represent these three states, if we want to avoid 
introducing new enums?  It seems to me its semantics aligns quite nicely 
with the problem at hand.

Fred


On 16/01/2021 17:41, Kevin Rushforth wrote:
> Hi Jonathan,
>
> Thanks for the suggestion. I thought about it as well. We could do 
> that, but it seems like overkill. I'll reconsider if enough others 
> favor the idea. As for the exception, my thinking is to use 
> UnsupportedOperationException, which is what the equivalent AWT method 
> uses. FWIW, I don't generally like checked exceptions; we don't define 
> any such exceptions in JavaFX and I wouldn't want to start now.
>
> -- Kevin
>
>
> On 1/16/2021 12:46 AM, Jonathan Giles wrote:
>> Hi friends,
>>
>> Just to throw out an alternate API approach (which I would not go 
>> anywhere near close to saying is a better approach), we could 
>> consider a three-value enum getter API:
>>
>> public static KeyLockState Platform::getKeyLockState(KeyCode keyCode);
>>
>> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT }
>>
>> I'll be the first to argue against yet another enum, but I wanted to 
>> throw this out there as an alternate approach that avoids the needs 
>> for checked exceptions (which is what I assume is meant by 'throw an 
>> exception', as opposed to throwing a runtime exception).
>>
>> -- Jonathan
>>
>> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth 
>> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>>
>>     For JavaFX 17, I am planning to add a minor enhancement to read the
>>     state of the keyboard lock keys, specifically, Caps-Lock,
>>     Num-Lock, and
>>     maybe Scroll-Lock (although I might defer the latter to a future
>>     version
>>     since it will be more difficult to test, and doesn't seem as 
>> useful).
>>
>>     This is currently tracked by JDK-8259680 [1].
>>
>>     The proposed API would be something like:
>>
>>              public static boolean Platform::isKeyLocked(KeyCode 
>> keyCode);
>>
>>     One question is whether we should throw an exception if the key 
>> state
>>     cannot be read on a particular system (e.g., Num Lock on macOS),
>>     which
>>     is what the similar AWT API does. I don't have a strong opinion on
>>     that
>>     poont, although I wouldn't want to throw an exception if the 
>> keyboard
>>     doesn't have the key in question, as long the system is able to
>>     read the
>>     state accurately.
>>
>>     Comments are welcome.
>>
>>     -- Kevin
>>
>>     [1] https://bugs.openjdk.java.net/browse/JDK-8259680
>>     <https://bugs.openjdk.java.net/browse/JDK-8259680>
>>
>