Proposal: Support Wayland and add KEM APIs

[Iris Clark]

In November 2023, Red Hat announced [0] their intent to remove the Xorg server
from RHEL 10; therefore, only Wayland will be supported in RHEL 10 and
subsequent releases.  Other Linux distributions may choose a similar path.

This will be an issue for Java SE 8, 11, and 17 as they only support the Xorg
server.

  - (JSRs 337, 384, 392) The Java SE 8, 11, and 17 specifications of
    java.awt.Robot make several assumptions about programmatic access to the
    desktop and related behaviours which may not be valid due to restrictions
    in underlying environments such as Wayland.  In Java SE 21, the
    specification was amended to allow operations to degrade or fail.  This
    specification change alone is sufficient to allow for variances in desktop
    behaviour. [1]

We would also like to add support in Java SE 17 for functionality required by
some Post-Quantum Cryptographic (PQC) algorithms.  The following new APIs are
necessary to support all of the candidate algorithms currently identified by
the U.S. National Institute of Standards and Technology (NIST) for PQC
standardization.  This will be an issue as:

  - (JSR 392) KEM APIs were added to Java SE 21 with JEP 452 (Key
    Encapsulation Mechanism (KEM) API) [2].  They support secure encryption
    techniques to derive symmetric keys using public key cryptography.  None
    of the existing cryptographic APIs in the Java Platform are capable of
    representing KEMs in a natural way. [3]

Finally, we would like to add the system property
"java.specification.maintenance.version" to Java SE 17, thus aligning it with
Java SE 8, Java SE 11, and releases Java SE 19 and beyond.  The issue is:

  - (JSR 392) The Java SE 17 Specification does not have a programmatic means
    to identify whether a JDK is implementing an original, or maintenance
    release of the Java SE specification.  The system property
    "java.specification.maintenance.version" was added in Java SE 19 and
    subsequently backported to Java SE 8 via MR 4 and Java SE 11 via MR 2. [4]

To resolve these issues for future JDK updates, I'll shortly propose
Maintenance Releases of the Java SE 8 [5], the Java SE 11 [6], and Java SE 17
[7] Platform JSRs in the JCP.  For Java SE 8 and Java SE 11, this will require
updates to the Specification only; for Java SE 17 this will require updates to
the Specification, the Reference Implementation (RI), and the TCK.  These will
be provided by me and my Oracle colleagues.  I expect the Maintenance Release
process to complete by July 2024, in time for these changes to be merged into
the October security releases of JDK 8, JDK 11, and JDK 17.

Following the standard practice, we will base the open-source RI on the most
recent RI for the release, rather than the most recent JDK Updates release.
We propose to label the RI build as "17.0.0.1" in order to convey that it is
outside the contemporary train of update releases.  It is neither meant for
production use, nor will it be updated with security fixes.

If it's not too much work, we'll also contribute the changes required by these
MRs to the next appropriate JDK 8, 11, and 17 Updates releases (most likely
8u432, 11.0.25, and 17.0.13 respectively).  We do not plan to backport the
DH-Based KEM implementation that was included in JEP 452.

Comments?

Iris

[0]: https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server
[1]: https://bugs.openjdk.org/browse/JDK-8308012 [Robot]
[2]: https://openjdk.org/jeps/452
[3]: https://bugs.openjdk.org/browse/JDK-8305384 [KEM]
[4]: https://bugs.openjdk.org/browse/JDK-8285764 [sys prop]
[5]: https://jcp.org/en/jsr/detail?id=337
[6]: https://jcp.org/en/jsr/detail?id=384
[7]: https://jcp.org/en/jsr/detail?id=392