https://bugs.openjdk.java.net/browse/JDK-8212700
On 10/18/2018 02:50 PM, Roger Riggs wrote:
Hi Phil,
Thanks for filing the issues and clarifications.
I agree that removal is a great option to reduce clutter and maintenance.
I forgot to include 'sun.desktop' which seems to be only ever set to
'gnome' on linux
and 'windows' on windows.
Near as I can tell that may mainly have been used to select between a
gnome & CDE/Motif desktop
Setting it to windows on windows didn't tell you anything new.
I've filed https://bugs.openjdk.java.net/browse/JDK-8212701
Also I've filed one for the AWT toolkit :
https://bugs.openjdk.java.net/browse/JDK-8212700
and another for fontpath : https://bugs.openjdk.java.net/browse/JDK-8212703
-phil.
Thanks, Roger
On 10/18/2018 05:39 PM, Phil Race wrote:
Adding 2d-dev .. as most of these are actually for 2D, not AWT,
despite the names.
I have bugs filed to get rid of these two 2D properties :
https://bugs.openjdk.java.net/browse/JDK-8130264 : java.awt.printerjob
https://bugs.openjdk.java.net/browse/JDK-8130266 : java.awt.graphicsenv
Probably I could file another for "awt.toolkit", which is AWT.
The potential external use of these to inject replacments was made
moot by jigsaw.
So I don't think I'd bother "moving" them, more like replacing them &
then deleting this code.
fontpath used to be used as a workaround for failure by 2D to locate
the system fonts
which probably is no longer needed due to better ways we have of
doing this these days.
We probably could remove that along with the code which reads it.
I'd have to think about where we could put the isInAquaSession() logic.
-phil.
On 10/18/2018 07:22 AM, Roger Riggs wrote:
Hi,
There are a few java.awt.* properties that have support in the
system.c native code based on
the operating system. Most do not need to be in native code and
decoupling the code
would be a good cleanup.
I'd like to look at the properties and move the initializations to a
more appropriate place.
Since they are not used in the java.base module it would be more
appropriate for
them to be handled in the java.desktop module and the appropriate
package.
At the moment, they all can be overridden by command line arguments
though
in some cases, that seems to be unintentional and perhaps undesirable.
Most could dispatch on the os_name system property to select the
appropriate implementation class.
I'd like to work through this issues and see if there are any
special considerations.
Thanks for any comments and advice.
Roger
java.awt.graphicsenv: java.awt.GraphicsEnvironment.java
"sun.awt.CGraphicsEnvironment" "sun.awt.X11GraphicsEnvironment"
"sun.awt.Win32GraphicsEnvironment"
awt.toolkit : java.awt.Toolkit.java
"sun.awt.X11.XToolkit" "sun.lwawt.macosx.LWCToolkit"
"sun.awt.windows.WToolkit"
java.awt.printerjob: java.awt.print.PrinterJob.java
"sun.print.PSPrinterJob""sun.lwawt.macosx.CPrinterJob"
"sun.awt.windows.WPrinterJob"
awt.headless: This may need native code specific to the Mac.
isInAquaSession() ? NULL :"true";
sun.java2d.fontpath: sun.font.SunFontManager
The native initialization is hooked to an environment variable
"JAVA2D_FONTPATH".
Is that initialization from the environment still used or needed?
--
Thanks, Roger
