Any Java application that references or imports a java class which
may have references to the AWT will stop working if the X DISPLAY
variable is not set. The java application should not stop working
simply because a class that has AWT components is imported. I
have developed a package that renders IDEF0 process models on a 
canvas. It turns out that this package is also useful for converting
IDEF0 models to other data formats. When attempting to print ASCII
data formats to the System.out stream and never intending to start an
windowing application, the java application simply stops because the X DISPLAY is
not set. In order to make classes useful, they should be re-usable.
Classes should not be limited to reuse as windowing classes or text
only classes. I should be able to use them for any purpose that I see
as necessary. Because of this AWT bug, I can only use my classes that
have windowing components as foreground windowing applications or applets.
These classes would be useful for background processing and/or CGI
programming in some instances, so there is a legitimate need for classes
to be able to operate both in a windowing mode and silently on the
command line. Because I have a class that knows how to draw itself
doesn't mean that the class has a limited scope of operation or usefulness.



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

======================================================================
  xxxxx@xxxxx   1998-11-06

(company - Space Telescope Science Institute , email -   xxxxx@xxxxx  )


One user reports:
I got around the problem by passing in DISPLAY as a property,
(easy since we start our application from a shell script), then
calling some code like the following.  This is for example only...
YOU must modify to suit your application:

    static public boolean display_ok() {
        // See if the local display is accessed
        if ( System.getProperty("DISPLAY").equals(":0.0")) 
            return true;
        
        // Check overall syntax
        StringTokenizer display = 
                new StringTokenizer(System.getProperty("DISPLAY"),":");
        if ( display.countTokens() != 2 ) {
            System.out.println("DISPLAY variable formed incorrectly: "+
                    System.getProperty("DISPLAY"));
            System.out.println("Correct format is: " + 
                "<Hostname>:<keyboard>.<mouse>");
            System.out.println("i.e.  foo:0.0");
            return false;
        }
        
        // See if host is valid
        String host = display.nextToken();
        InetAddress address;
        try {
            address = InetAddress.getByName(host); 
        } catch ( Exception e ) {
            System.out.println("Could not find host:"+host);
            return false;
        }    
        
        // Check syntax of keyboard and mouse
        StringTokenizer test_kyb_mouse = 
                new StringTokenizer(display.nextToken(),".");
        if ( test_kyb_mouse.countTokens() != 2 ) {
            System.out.println("DISPLAY variable formed incorrectly");
            System.out.println("The Keyboard and Mouse portion is incorrect");
            System.out.println("Correct format is: " +
                 "<Hostname>:<keyboard>.<mouse>");
            System.out.println("i.e.  "+host+":0.0");
            return false;
        }
        
        // See if the server is running
        String port = System.getProperty("xport");
        if ( port == null ) 
            port = "6000";
        int port_no;
        try {
            port_no = Integer.parseInt(port);
        } catch ( Exception e ) {
            System.out.println("The command line option must" +
                "be an integer number");
            System.out.println("i.e.  -xport 6000");
            return false;
        }
        
        Socket socket;
        try {
            socket = new Socket(address, port_no);
        } catch (Exception e) {
            System.out.println("No X-Server is running on host, "+
                        host+", port, "+ port+".");
            return false;
        }
        
        // Test for X Server permission
        try {
            Toolkit tk = Toolkit.getDefaultToolkit();
        } catch (Error e) {  
            System.out.println("X-Server access is denied on host, "+host);
            return false;
        }
        
        // release the test socket
        try {
            socket.close();
        } catch ( Exception e ) {
        }
        socket = null;      

        return true;
    }


The only hitch is the ugly Xlib messages that are
printed when an X-server denies access.

Xlib: connection to "abc:0.0" refused by server
Xlib: Client is not authorized to connect to Server
X-Server access is denied on host, abc

6/3/2000   xxxxx@xxxxx   --  The issue is that an X server is required.  This is
covered in other bugs, and particularly in 4281163, which (as of today) has 169 
Bug Parade votes.

Based on the support for the latter bug #, am duping this bug to # 4281163.

So, I shouldn't do import java.awt.* if I'm not
doing GUI??? It hit me as a bad surprise today,
when my application issued: "Can't connect to X11
window server using :0.0 as the value of the
DISPLAY variable" when it wasn't clear at all
*why* is it trying to connect (until I saw the
import statement in the .class being loaded)...

In the work-around, the DISPLAY variable syntax is incorrect.
There is no such "mouse" portion. 
The syntax for DISPLAY is [host]:server[.screen]    where the brackets
indicate optional components. 
More info is in "X Window System User's Guide, Motif Editon", page
63.

What about workarounds for code that actually needs to talk to an XServer?
For example, we have some thirdparty software that renders PDF's on our 
servers, but it needs fonts and other awt components that need X. I tried a vnc
server,
but that didn't work. It seems that jdk1.2.2 for solaris must have Xsun.

The solution proposed above is utterly useless. Clearly the poster does not
understand the problem.The problem is, restated, how does one suppress
AWT from attempting to open a display, when AWT classes are only used
tangentially? My example is from a Client/Server application I'm building. I
have
a class that parses and stores database fields on the server side, is then
serialized and transmitted to the client via Java's object serialization, and
then generates a AWT-based GUI appropriate for the data stored. The problem
is that the server does not have a valid DISPLAY variable, and even though
the class does not directly generate AWT components on the server, because
that class *references* AWT classes, it still triggers AWT's static
initializers,
and attempts to open the display. My suggestion to the Java development team
is:
don't use static initializers. It's bad practice in general. Too late now,
though. 
To fix this particular problem, I would suggest that the JDK/JRE support a
property called, say, 'java.awt.ignore', which, if true, would ignore all AWT
component requests,
effectively detaching the GUI. In the meantime, I have been using one of two
workarounds:
1. Split the class into two classes, one which accesses the AWT, and one which
does not.
2. Set the DISPLAY variable to a valid X host that no one actually uses
(fortunately,
we have several of these lying around).
3. A third workaround I've thought of, but haven't had time to implement yet,
is to replace the
AWT dynamic library file with one that does nothing. This would require a fair
degree
of reverse engineering.
These are both, obviously, ugly solutions.