java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

This problem looks almost identical to the 4203151 bug reported on the
awt.toolkit class failure to be found. The resolution to the problem in the
awt.toolkit case turned out to be (response text taken from 4203151):

 java.awt.Toolkit.getDefaultToolkit must be using
 Class.forName(toolkitName, true, ClassLoader.getSystemClassLoader())
 instead of the plain Class.forName().

In the java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment() method we see
the following code:

        localEnv = (GraphicsEnvironment) Class.forName(nm).newInstance();

I would appear that the same mistake of using forName() instead of the version
of the method that takes a class loader has been made.

The result is that you cannot replace the local graphics environment in the
current JDK. Using the -Xbootclasspath trick to get your class into the system
code will allow the class to be found, as was the case with the awt.toolkit
problem. However, unlike the awt.toolkit problem, there is a second problem once
the first is bypassed, and that is that an IllegalAccessException is thrown by
the Class.forName(nm).newInstance() attempt. Modifying the java.policy file to
give all security and io permissions does not recitify the problem, so the local
graphics environment cannot be replaced. I have tried this both on the WindowsNT
and Solaris versions of the JDK, with no success.

I have seen several forum questions related to this problem, especially in
Solaris environments, when the programmer doesn't want the native X11 graphics
environment, so there are people out there experiencing the same problem. For
example: http://forum.java.sun.com/read/16804183/q_MwvIm_oY80AAAlC#LR. Please
fix this problem. Thanks.
(Review ID: 110751) 
======================================================================

N/A

Reassiging to 2D at the request of   xxxxx@xxxxx  .  I am also raising 
the priority so it doesn't get lost - this is now #5 on the JDC.  
  xxxxx@xxxxx   2001-07-30

===============================

Unfortunately this is not a documented, or supported, or public property
and is not designed for the use requested.
It is an implementation property used to pick up the appropriate platform
implementation of the class for the platform on which the JRE is running.

This implementation class is of course part of the JRE so the usage of
class.forName() is correct.

I'm not sure what all the reasons might be for requesting this feature, but
based on a comment in the description it seems that a sizeable number of
the developers who are trying to do this are doing it as part of an
attempt to avoid unnecessary connections to the X server in cases where
the application is primarily a server one. Changing the classloader behaviour
as requested in this bug is not needed for that purpose as 1.4 has a much
simpler way of getting that behaviour by using the new headless toolkit.

  xxxxx@xxxxx   2001-07-31
========================

As was suggested above, this is not a publicly supported property so I
am closing this as not a bug.  
  xxxxx@xxxxx   2001-07-31

<b>This bugs prevents our company from having a 'headless 
server'. We are targetting ASP businesses that have banks 
of sun boxes and without this fixed, our product will be 
rejected. PLEASE FIX </b>.

I am incredibly annoyed at such a serious bug in 1.3. What a pain to work around. PLEASE FIX

Why so many votes, but so few comments explaining why this
is a particular problem. The headless server need is
satisfied in 1.4 by using the headless toolkit.

See bug ID: 4513617.  This is more of a reason why this is a bug, and why a headless environment won't fix 
this problem.