New API to read Caps-Lock and Num-Lock state
Frederic Thevenet
thevenet.fred at free.fr
Sun Jan 17 11:28:32 UTC 2021
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>
>>
>
More information about the openjfx-dev
mailing list