Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8223417

Change the mechanism by which JDK loads the platform-specific AWT Toolkit

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P4
    • Resolution: Approved
    • Fix Version/s: 13
    • Component/s: client-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      Hide
      This change just eliminates the system property so is low.
      The only risk is code that expects the property to be defined and tries to use its value getting an NPE, however application code has no reason to inspect this value.
      Show
      This change just eliminates the system property so is low. The only risk is code that expects the property to be defined and tries to use its value getting an NPE, however application code has no reason to inspect this value.
    • Interface Kind:
      Java API, System or security property
    • Scope:
      JDK

      Description

      Summary

      Remove the awt.toolkit system property, which is used to name the platform-specific internal subclass of java.awt.Toolkit

      Problem

      This is somewhat similar to JDK-8222990 which removed a system property used to specify the name of the platform's java.awt.GraphicsEnvironment implementation class, but this case has a longer history and greater prominence. The awt.toolkit system property has been used since JDK 1.0 (!) to specify the name of the implementation class for the AWT Toolkit. The platform over-ride value was hard-coded into the platform-specific code to initialise the system properties.

      Also the name of the property was documented on the API javadoc for java.awt.Toolkit.getDefaultToolkit().

      It was only in JDK 9, CCC-8130478 was submitted to remove mention of the awt.toolkit System property from the javadoc since it implied thatthere was an SPI whereby the toolkit was pluggable by code outside the JDK, but this is not the intention and in any case was now impossible due to the module system encapsulating and hiding internal classes it would be necessary to use.

      So JDK 9 made the big change: to remove the documentation and any possibility to make use of this system property by external code.

      But it remains up until now that the JDK is still using it internally and this pollutes launcher code with the system property so that the launcher must know the internals of the java.desktop module.

      Solution

      Remove the awt.toolkit system property which is used to specify the name of the platform implementation class.

      It is replaced by a mechanism entirely internal to the java.desktop module.

      Additionally, update the javadoc of java.awt.Toolkit.getDefaultToolkit() to reflect that AWTError is no longer thrown due to failed location of the class, since the dynamic class lookup necessitated by the previous scheme is no longer used. However AWTError may still be thrown (per existing javadoc) in case of failure to load an assistive technology. This should be added to the @throws clause.

      Specification

      1) remove the awt.toolkit system property

      2) Update the javadoc in the class java.awt.Toolkit :-

      public static synchronized Toolkit.getDefaultToolkit()
      ...
      -     * @exception  AWTError  if a toolkit could not be found, or
      -     *                 if one could not be accessed or instantiated.
      +     * @throws  AWTError in case of an error loading assistive technologies.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                prr Philip Race
                Reporter:
                prr Philip Race
                Reviewed By:
                Sergey Bylokhov
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: