Swing apps in general work poorly on remote X displays, Exceed included. The only other time I recall hearing from an Exceed user here, they were having difficulty with it, and I didn't hear back from them.

There are two major issues with remote X-Swing. One is that the JVM stupidly roots around on the JVM's Host's disks looking for fonts for the display. Thus, the thing finds the fonts on the JVM host instead of the X Display.

Second, the JVM double-buffers everything and does some other things which work great on console displays but slow down horribly on remote displays. It's possible to write your swing code to disable double buffering and work around the incorrectly-loaded fonts, but for 3rd party apps like JBuilder this isn't an option since you don't have the sources.

---
Sun's JVM has an unfortunate design when it comes to remote X server support.

The JVM roots around on the host's physical disks looking for fonts instead of using X11's built-in font query support. So, the JVM is using font metrics and selections for the host itself, not your Exceed X server.

The square box is displayed whenever a character is used which does not have a usable glyph in the display's fonts. I suspect the JVM is using a Solaris font which your Exceed X server doesn't possess, so Exceed has to substitute.

Note: Sun's JVM requires that some optional Solaris packages be installed to provide some additional fonts required by the JVM. They aren't listed in the list of patches since they're provided on the Solaris media. I don't think this is causing your machine's problem but it's worth mentioning since it's tripped up a number of Solaris users lately.
---
Java apps in general run horribly on remote X terminals and emulators. The JVM and the API all assume the display is physically attached to the host running the code. For instance, the JVM ignores X's intelligent font query support and goes rooting around the host's disks for fonts instead. The JVM ends up using Fonts known to the host but not necessarily to the terminal/emulator running the display.

Another big issue is that the graphics is double-buffered and transfered pixel by pixel to the display. This runs decently on a local display but the bandwidth required to transmit it to a terminal/emulator degrades performance to the point of unusability.

There are some workarounds the developers can make, such as disabling double buffering to improve the remote display speed somewhat, but these don't fix the broken font handling.

If you're trying to run any large Java app remotely, I'd consider something like VNC instead. I haven't tried it specifically with Java, but we're using it here for a lot of development work with good results.
2001-Aug-01 10:22am gyles19@visi.com