Bug ID: JDK-8130266 Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 13
13 b21Fixed

It was noted that we use reflection on a class name located via a system property
to locate the GraphicsEnvironment class

File: jdk/src/java.desktop/share/classes/java/awt/GraphicsEnvironment.java
[M] Line: 111 'ge = (GraphicsEnvironment)geCls.newInstance();'
 java.awt.graphicsenv property defines the GraphicsEnvironment class. 

This can be misconstrued as being an external SPI layer. In fact it was
just a convenience to locate the right class depending on whether we
were Sun JDK for (1) solaris or (2) windows (back in the 1.2 days).
A JDK port could consider that part of its porting layer. But it was
not for use outside JDK.

To avoid polluting the system properties name space we could consider
an alternative means to locate the class.

commit https://github.com/openjdk/jdk/commit/d43616c60a3d90258212da433ba8c2d58ade243d Author: Phil Race <prr@openjdk.org> Date: Mon Apr 29 10:16:58 2019 -0700
17-04-2024
URL: http://hg.openjdk.java.net/jdk/jdk/rev/99337f94b04d User: psadhukhan Date: 2019-05-15 09:11:03 +0000
15-05-2019
URL: http://hg.openjdk.java.net/jdk/client/rev/99337f94b04d User: prr Date: 2019-04-29 17:18:08 +0000
29-04-2019
We need something very much like what was done for the PrinterJob class here : https://bugs.openjdk.java.net/browse/JDK-8130264 Once we have that then we can also push down into those classes some X11 specific knowledge that is in the shared SE API class GraphicsEnvironment (!) that defaults to headless if there is no X11 display environment variable set. Such a platform class would also be the right place for the implementation code that does something similar for MacOS, using a native method which checks if JDK is running in an aqua desktop session. That would have the benefit of decoupling it from the AWT toolkit, since it is something that both the Toolkit and the GraphicsEnvironment may need to know and we have to be careful not to have any cyclic dependencies between those two classes.
25-04-2019
Can we get this cleanup done in the next release. There are still unnecessary java.desktop property dependencies in the system.c native code. There is a need, it is not just nice to have.
05-02-2019
The Rampdown phase start [1] milestone is approaching, it means we are not targeting "9" to fix P4s anymore, unless the fix is ready and not risky, safe enough not introduce P2-P3 regressions; if this is a case you can retarget back to "9" right before the push the reviewed code. [1] http://openjdk.java.net/projects/jdk8/milestones#Rampdown_start
29-08-2016

CSR :	JDK-8222990 - Change the mechanism by which JDK loads the platform-specific GraphicsEnvironment class
Relates :	JDK-8212700 - Change the mechanism by which JDK loads the platform-specific AWT Toolkit
Relates :	JDK-8273581 - Change the mechanism by which JDK loads the platform-specific FontManager class
Relates :	JDK-8222819 - Remove setting of headless property on MacOS from launcher code.
Relates :	JDK-8212701 - remove sun.desktop property from launcher code