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

[Frederic Thevenet]

I realize that my suggestion was somewhat unclear, apology about that.

I wasn't suggesting that we return null to count as the third state, but 
indeed that we leverage the isPresent state of the optional, alongside 
with the two states provided by the Boolean, e.g:

isKeyLocked(KeyCode.NUM_LOCK).ifPresent(locked-> {
     // The num_lock key exists on the current platform
     if (locked){
         // React to the key being locked
     } else {
         // Or to the key not being locked
     });


On 17/01/2021 18:31, Jonathan Giles wrote:
> A method returning Optional should never return null, as that undoes 
> the contract that Optional is supposed to represent, which is to avoid 
> NPEs by never being null itself, only empty in the absence of a 
> returned value. For this reason, an Optional should be considered two 
> state rather than three state.
>
> -- Jonathan
> (Tapped on a touch device)
>
> On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet, 
> <thevenet.fred at free.fr <mailto:thevenet.fred at free.fr>> wrote:
>
>     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>
>     <mailto: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>
>     >>     <https://bugs.openjdk.java.net/browse/JDK-8259680
>     <https://bugs.openjdk.java.net/browse/JDK-8259680>>
>     >>
>     >
>