JDK-8223417 : Change the mechanism by which JDK loads the platform-specific AWT Toolkit
  • Type: CSR
  • Component: client-libs
  • Sub-Component: java.awt
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 13
  • Submitted: 2019-05-06
  • Updated: 2019-07-19
  • Resolved: 2019-05-10
Related Reports
CSR :  
Relates :  
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.
```
Comments
Moving to Approved. The release notes are better tracked on the parent issue rather than the CSR.
10-05-2019

Given the long - from the first days - history of this property, I deem it release-note worthy, so have added the label.
07-05-2019