Installation

Answers in this category:
How can I get JBuilder to use my mouse wheel?
I cannot get Cut and Paste to work between JBuilder and the rest of Linux. Does anyone know how to make this work?
Sun JDK 1.3 screws up non-English keyboards?
What does "Font specified in font.properties not found [--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] " mean?
"Warning: Cannot convert string "Home,_Key_Begin" to type VirtualBinding"
I want to run JBuilder 3.5 on JDK 1.3.
Solaris: Cannot start Java debug process VM
The fonts provided with Sun's JVM for Linux SUCK. How can I replace them?
JBuilder's IDE is much more sluggish on Linux than it is on Windows. How can I make it snappier?
JBuilder references a font I don't have: "Nimbus Mono B" Where can I find it?
JBuilder4 on Solaris 7 debugging is disabled
I'm using KDE 2 with JBuilder 4/5/6 and I'm having painting/display/keyboard problems.
What's up with the new kernels and this LD_ASSUME_KERNEL stuff?
I installed JBuilder 5 on Mandrake 8.0. Whenever I build a project, JBuilder's JVM dumps core with the following message: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x501c33a8 Function name=PV_ProcessSequencerEvents Library=/usr/java/jdk1.3.1/jre/lib/i386/libjsound.so Current Java thread:at com.sun.media.sound.MixerThread.runNative(Native Method)
My XFree86 dumps core when I try to run java applications which use java3d. What's wrong?
I want to use JBuilder with a remote Xterminal using Exceed or some other remote X package, or even an HDS terminal. Why doesn't this work well?
How can I automatically log JBuilder's own exceptions?
I'm trying to run JBuilder 6 on Red Hat 7.2 with the Sawfish window manager. CodeInsight windows appear minimized. How can I make them appear normally?
I have JBuilder 4 installed on Red Hat 7.2. Yesterday I updated my kernel from 2.4.9-13 to 2.4.9-21, and now JBuilder won't launch.
How can I use XFree86's XNest server to correct the problems encountered running JBuilder 6 on KDE 2.2 and other window managers where CodeInsight malfunctions?

Answers in this category:
Xlib: connection to "joi:0.0" refused by server
How much space is required to install JBuilder 4 Foundation?
JBuilder won't install. How do I debug the installer?
Where is Borland's Linux Installation FAQ?
I have Red Hat 7.0 and I'm having difficulties installing/running JBuilder/Java.
InstallAnywhere claims my install package is corrupt, but the package is fine.
Where is Borland's Solaris Installation FAQ?
Solaris: When I try to launch JBuilder for the first time, the JVM dumps core. What's wrong?
Failure launching JBuilder4 on Solaris: java.lang.IllegalArgumentException: Unknown signal: HUP
JBuilder 4 Foundation won't install on my Mandrake 7.2 system!
I run Linux on a PowerPC Macintosh. Can I install JBuilder4?
...this program needs Java Virtual Machine Installed in prior....
Installing JB4 on Solaris 2.6 with JDK 1.2.1 yields error: "Exception occurred during event dispatching:java.lang.NoSuchMethodError: java.lang.Runtime: method addShutdownHook(Ljava/lang/Thread;)V not found
JBuilder won't run on Red Hat 7.1/SuSe 7.x/Mandrake 8.x
My machine is running an SMB kernel and Java apps are unreliable. What are my options?
I've installed JBuilder on Linux and my keyboard dosn't work at all!
I have downloaded the jb4fndlinux.tar.gz twice now and when I run "tar -xvf" on it, bash tells me: "tar: This does not look like a tar archive/ tar: Skipping to next header/ tar: 394 garbage bytes ignored at end of archive/ tar: Error exit delayed from previous errors"
I've just installed JB4 Foundation on Solaris 2.6. I've applied all of the Solaris patches required by JDK 1.3. When I try to launch jbuilder, I get the following error: /opt/jbuilder4/bin/jbuilder[47]: ./*.config: not found. What is wrong?
Jbuilder 4 and Red Hat 7.1 - license dialog hangs
I'm trying to install JBuilder 5 on Solaris 2.7 but I'm getting the following error message: /tmp/install.dir.24417/Linux/resource/jre/bin/java: test: argument expected
On what Linux distributions does Sun support SDK 1.3.1?
Exception in thread "main" java.lang.InternalError: Can't connect to X11window server using ':0.0' as the value of the DISPLAY variable.
What is JBCheck and what does it do?
Will JBuilder6 run on FreeBSD in Linux-emulation mode?
I have JDK 1.4.0 beta 3 on my Red Hat 7.2 box. I can't get JBuilder5 to install.
I'm trying to install the JBuilder Personal Documentation on LInux but it fails with this error, followed by a stack trace: "Error: Unrecognized JVM specific option `-Xmx50331648'. Error: Unrecognized JVM specific option `-Xms16777216'. Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)"

This error means that the X server referenced in your DISPLAY variable refused 
to allow the installer to open a window.  Typically this is caused by the X11
process running under a different username than the username which is attempting
to install JBuilder.  This is an X11 security feature which must be pacified or
disabled before the installer will function.

An easy workaround is to issue the command "xhost +" in an existing window on
the X display, using a shell which is logged in under the same username as which
launched the X11 process.  "xhost +" tells the X11 process that any host and 
user may open a window on the display.  


Complete error message:

[jamie@joi cdrom]$  ./install_linux
Xlib: connection to "joi:0.0" refused by server
Xlib: Client is not authorized to connect to Server
LAX: Method.invoke() threw an InvocationTargetException:
java.lang.InternalError: Can't connect to X11 window server using 'joi:0.0' as the value of the DISPLAY variable.
        at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
        at sun.awt.X11GraphicsEnvironment.clinit(X11GraphicsEnvironment.java:58)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java, Compiled Code)
        at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:59)
        at java.awt.Font.initializeFont(Font.java:258)
        at java.awt.Font.init(Font.java:288)
        at javax.swing.plaf.metal.DefaultMetalTheme.init(DefaultMetalTheme.java:55)
        at javax.swing.plaf.metal.MetalLookAndFeel.createDefaultTheme(MetalLookAndFeel.java:705)
        at javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(MetalLookAndFeel.java:709)
        at javax.swing.UIManager.setLookAndFeel(UIManager.java:359)
        at javax.swing.UIManager.setLookAndFeel(UIManager.java:386)
        at com.borland.integration.tools.launcher.launcher.main(launcher.java:47)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.zerog.lax.LAX.a([DashoPro-V1.2-120198])
        at com.zerog.lax.LAX.main([DashoPro-V1.2-120198])
LAX: exiting.

These numbers were acquired with the JBuilder 4.0 Enterprise CDROM and selecting a CUSTOM installion of Foundation only.
2000-Dec-20 1:18pm gyles19@visi.com

Please do the following, substituting appropriately where I've used {}.
I've just performed these steps on my Red Hat box and logged/saved everything
for reference.  I'm using the Foundation installer bin file from my
Enterprise CDROM.

Open an xterm window for the user which will run JBuilder. Don't use root.
---------------------------------------
$ cd /tmp
$ script foobar.log
$ df -k .
$ df -k ~
$ which ls
$ which uncompress
$ which dd
$ which df
$ which rm
$ which dirname
$ which basename
$ LAX_DEBUG=file /bin/sh -xv {/mnt/cdrom/linux_sol/fnd_linux_install.bin}
---------------------------------------

If the installer launches, install JBuilder Foundation into your home
directory.  When you get to the last page of the installer, where it
says it completed, pause, do the following in a different shell window.

If the installer didn't launch, do the following if the files are present:

---------------------------------------
$ cp env.properties.{*} save.env.properties
$ cd /tmp/install.dir.{*}
$ cp install.log.temp ..
$ cp sea_loc ..
$ cp temp.lax ..
---------------------------------------

Now exit the installer by clicking its button.

Now, in the window you ran the installer from, close the script log:

---------------------------------------
$ exit
---------------------------------------

Now you have a bunch of stuff in /tmp:

-rw-rw-r--    1 trinity  trinity   2183168 Dec 20 14:06 foobar.log
-rw-r--r--    1 trinity  trinity     14315 Dec 20 14:08 install.log.temp
-rw-rw-r--    1 trinity  trinity        43 Dec 20 14:08 sea_loc
-rw-rw-r--    1 trinity  trinity       778 Dec 20 14:08 temp.lax
-rw-r--r--    1 trinity  trinity      2437 Dec 20 14:09 jx.log

Look this stuff over, especially foobar.log, and see if there are any error
messages visible in the log which pinpoint the problem.  If you can't find 
anything, I'll compare it with my own install logs.

To send me the stuff, do the rest below:

---------------------------------------
$ tar czf foobar.tgz foobar.log install.log.temp sea_loc temp.lax jx.log
---------------------------------------

There are two big subdirectories under here I DO NOT want, that's why
I'm listing these files manually instead of using *.

Email me the foobar.tgz file and I'll compare it to my own.

  http://community.borland.com/article/0,1410,26055,00.html

  http://community.borland.com/article/0,1410,20706,00.html

  http://community.borland.com/article/0,1410,26034,00.html

Note that Red Hat has been announcing rpm fixes faster than Borland can keep up with them. The page referenced above has links to rpms which may have been superceeded. Look around in the same area for newer ones.

Also note that there may be some bugs in 7.0's libpthreads which may affect your ability to run native thread JVMs. One such bug causes Sun's JVM to always return a zero return code from subprocesses even if those subprocesses died with errors.

  http://developer.java.sun.com/developer/bugParade/bugs/4388732.html

2001-Jan-22 10:00pm gyles19@visi.com

From: Gary Sanders

Folks,

I found a problem with the JB4 _installer_.  The problem manifests
itself as an error message that your download was corrupted, but the
problem is not that the download got corrupted.  The problem is that the
InstallAnywhere script tries to use enormous block sizes, and it
corrupts the files when there isn't enough free memory available on your
system - and increasing the swap or tmp space does NOT resolve the
problem!

The InstallAnywhere installer is actually a script follwed by padding,
followed by the JVM ( as a binary, compressed, tar file ), then followed
by JB4 itself ( also a binary, compressed, tar file ).  The script
portion uses dd with a block size of 32768 to extract the binary, but
that includes some padding or the JB4 file at the end of it so they call
it again, but this time with one huge block size of approx. 16MB to trim
it to it's proper size.  The 32768 makes it really slow, because the
actual block size for most Linux systems is 1024, but it's the approx.
16MB block that "dd" or the Linux kernal barf on.

The solution is simple.  First copy your original "dd" file (
/usr/bin/dd ) to a safe location - you'll want it back later.  Then,
just for the installation of this file, replace "dd" with the script
below ( and don't forget to make it executable ( chmod +x dd )). This
script  looks at the block sizes and count passed in and determines the
total bytes desired.  Then it splits that up into blocks of 1024 with
the appropriate remainder at the end if needed.   Not only does it work,
it even runs faster since the block size is the same as that of the OS
itself.

When the install is finished, be sure to copy your original "dd" back
into place.

#!/usr/bin/perl

foreach $arg ( @ARGV ) {
    ($k,$v) = split( "=", $arg );
    $args{$k}=$v;
}

$totalBytes = $args{'bs'} * $args{'count'};
$skip = $args{'skip'} ;

open( INFILE, $args{'if'} ) || die;
open( OUTFILE, "> $args{'of'}" ) || die;

( seek( INFILE, ( $args{'skip'} * $args{'bs'} ), 0 ) || die )
    if ( $args{'skip'} > 0 );

$tbs = ( $totalBytes > 1024 )? 1024 : $totalBytes;
while ( $r = read( INFILE, $data, $tbs ) ) {
    syswrite( OUTFILE, $data, $r );
    $totalBytes -= $r;
    $tbs = ( $totalBytes > 1024 )? 1024 : $totalBytes;
}

close( INFILE ) || die;
close( OUTFILE ) || die;

  http://community.borland.com/article/0,1410,26087,00.html

For JBuilder 3.5:

  http://community.borland.com/article/0,1410,21812,00.html

  http://community.borland.com/article/0,1410,28125,00.html

For JBuilder 5.0:

  http://community.borland.com/article/0,1410,28124,00.html

http://www.java.sun.com/j2se/1.3/install-solaris-patches.html
2000-Dec-19 9:22pm gyles19@visi.com

> After installing JBuilder 4 Enterprise Edition we got the following
> error message when starting the program. We are running Solaris 2.8 on a
> SPARC ULTRA 10.
>
> Exception occurred during event dispatching:
> java.lang.IllegalArgumentException: Unknown signal: HUP
>         at sun.misc.Signal.init(Signal.java:133)
>         at java.lang.Terminator.setup(Terminator.java:46)
>         at java.lang.Shutdown.add(Shutdown.java:92)
>         at java.lang.Runtime.addShutdownHook(Runtime.java:197)
>         at com.borland.primetime.ide.Browser.init(Unknown Source)
>         at com.borland.jbuilder.rb.run(Unknown Source)
>         at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:156)
>         at java.awt.EventQueue.dispatchEvent(EventQueue.java:300)
>         at java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:105)
>         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:95)
>         at java.awt.EventDispatchThread.run(EventDispatchThread.java:86)


Install the final release of J2SE 1.3, not the beta.

The file ncompress-4.2.4-21mdk.i586.rpm is on your Mandrake "inst" disc. Something like the following sequence of instructions should work. You may need to adjust the path to your cdrom device.

  su - root
  mount /mnt/cdrom
  cd /mnt/cdrom/Mandrake/RPMS
  rpm --install ncompress-4.2.4-21mdk.i586.rpm
  exit

Now when you launch the JBuilder4 installer it should now function properly.
2001-Mar-29 7:35pm gyles19@visi.com

The JBuilder startup scripts will need to be manually adjusted to point to the Blackdown JDK.

JB4 is reported to run perfectly on a Mac G4 running PowerPC Linux.

Borland does not support JB4 on this configuration, of course.
2001-Apr-01 11:34am gyles19@visi.com

You need to specify a VM for the installer to use, or put the VM on your system path. The former is probably easier. Use step 5 described here:

http://community.borland.com/article/0,1410,26055,00.html
2001-Apr-05 5:24pm gyles19@visi.com

  Exception occurred during event dispatching: java.lang.NoSuchMethodError:   java.lang.Runtime: method addShutdownHook(Ljava/lang/Thread;)V not found
        at com.borland.primetime.ide.Browser.[init](Unknown Source)
        at com.borland.jbuilder.rb.run(Compiled Code)
        at javax.swing.SystemEventQueueUtilities.processRunnableEvent(SystemEventQueueUtilities.java:354)
        at javax.swing.SystemEventQueueUtilities.access$0(SystemEventQueueUtilities.java:350)
        at javax.swing.SystemEventQueueUtilities$RunnableTarget.processEvent(SystemEventQueueUtilities.java:391)
        at java.awt.Component.dispatchEventImpl(Component.java:2381)
        at java.awt.Component.dispatchEvent(Component.java:2294)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:258)
        at java.awt.EventDispatchThread.run(Compiled Code)

Solution: JBuilder4 requires JDK 1.3.0 or better for its own operation. Download a 1.3 or better JDK from Sun and be sure to check its readme/installation notes for the required Solaris patch packages and font packages.
2002-Mar-29 9:56am gyles19@visi.com

In order to get a stock or upgrade RedHat 7.1 (i386) system to run Sun JDK 1.3.0_02 the following two changes must be made:

1. Create a symbolic link from /bin/cut to /usr/bin/cut

   ln -s /bin/cut /usr/bin/cut

2. Modify the $JAVA_HOME/bin/.java_wrapper script by adding the following two links after the copyright comments:

   LD_ASSUME_KERNEL=2.2.5
   export LD_ASSUME_KERNEL

Blackdown's 1.3.1 beta may work with Red Hat 7.1 without the above workarounds.
2001-Apr-25 10:22am gyles19@visi.com

Some platforms may need to install ksh (korn shell).
2001-Apr-26 6:04pm gyles19@visi.com

Conectiva 6.0, a Brazailian version of Red Hat, also needs the ncompress package.

2001-Jul-13 10:24am gyles19@visi.com

Sun Bug Parade item

  http://developer.java.sun.com/developer/bugParade/bugs/4441425.html

Known JVM versions that have this problem:

  jdk 1.3.1 RC1

  Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc1-b21)
    Classic VM (build 1.3.1-rc1-b21, green threads, nojit)

Workaround: change the default stack size to any number but "unlimited". e.g.

    ulimit -s 8192

On some Red Hat 7.1 systems: While completing the license dialog, JBuilder dumps core the moment you click the 'Ok' button after entering your keys.

Launching 'jbuilder -verbose -license' eventually displays it as:

SIGSEGV 11 (*) segmentation violation
    si_signo [11]: SIGSEGV: (*) segmentation violation
    si_errno [0]: Success
    si_code [1]: SEGV_MAPERR [addr: 0x1]

        stackpointer=0x49f41b08

Full thread dump Classic VM (J2RE 1.3.0 IBM build cx130-20000815, native threads):
    "Screen Updater" (TID:0x403383e0, sys_thread_t:0x8637b40, state:S, native ID:0x2c0c) prio=4
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:421)
        at sun.awt.ScreenUpdater.nextEntry(ScreenUpdater.java:79)

Since the IBM JVM bundled with JB4 is basically crap, simply replace it. I do not know why the bundled JVM dumps core on RH7.1, but I'm not going to waste any time debugging it since there are better JVMs available.

Go download Sun or Blackdown 1.3.1 (your choice.) Install it on your machine somewhere. (If you really wish to stay with IBM's JVM, go to their website and download the latest JVM they offer.)

Make a backup copy of jbuilder4/bin/jdk.config.

Now, edit jbuilder4/bin/jdk.config and replace all paths which refer to the IBM jvm with corresponding paths for the Sun/Blackdown JVM you just installed. Save the new file.

Check your machine's process list with 'ps' and make sure there aren't some defunct java processes left over from the IBM JVM's previous runs. Kill any leftovers you find.

Now you should be able to launch jbuilder -license and successfully complete the license dialog.
2001-Jun-07 8:12pm gyles19@visi.com

I am running 4.0 Enterprise on Redat 7.1 . I discovered the same problem. My current, though not complete fix, is to download the jdk1.3.1b24 from Sun. In jbuilder4/bin edit the jbuilder shell to point to the newly installed java. This will work. To get rid of the annoying font problems:

1> Download the URW fonts from http://www.gimp.org/urw-fonts.tar.gz

2> Untar the file in your X11R6 fonts directory. Usually this is /usr/X11R6/lib/X11/fonts (i.e. tar zxvf urw-fonts.tar.gz)

3> Modify the xfs config file. The file is /etc/X11/fs

4> Add the line /usr/X11R6/lib/X11/fonts/URW to the catalogue. Make sure each line has a comma at the end, except the last line of the catalogue command. Here is how mine looks:

  catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled,                            

  /usr/X11R6/lib/X11/fonts/75dpi:unscaled,
            /usr/X11R6/lib/X11/fonts/URW,
            /usr/X11R6/lib/X11/fonts/misc,
            /usr/X11R6/lib/X11/fonts/Type1,
            /usr/X11R6/lib/X11/fonts/Speedo,
            /usr/X11R6/lib/X11/fonts/75dpi,
            /usr/share/fonts/default/Type1

5> Restart xfs (i.e. /etc/rc.d/init.d/xfs restart)

BABAAM!!! You're up and running. My only problem thus far is the inability to use the debugging facilities ( which is no change from before ).

PS. If you want to find out what's happening when JBuilder "hangs", run it using the jbuilder/bin script and watch...
2001-Jun-18 7:28pm gyles19@visi.com

  mount -t iso9660 /dev/cdrom /mnt/cdrom

Conjecture: Mandrake's automounter is mounting the platter with an invalid partition type? Manually mounting with the correct type seems to work.
2001-Jun-25 10:59am gyles19@visi.com

   #! /bin/sh --login

fixes his runtime errors.

What this actually fixes, I have no idea.
2001-Jul-13 10:32am gyles19@visi.com

One user had something else. By editting jbuilder4/bin/jbuilder and appendending "-xv" to the very first line, and to line 65's ksh command, it became evident that /bin/sh on his machine didn't recognize the "function" keyword.

The solution we used here was to edit jbuilder4/bin/jbuilder once again, remove the "-xv" we added before, and change the first line to read "/bin/bash" instead of "/bin/sh".

An alternative would have been to symlink /bin/sh to /bin/bash, but since this could have repercussions elsewhere on the system I didn't recommend doing it.
2001-Jul-17 11:38am gyles19@visi.com

Installing JBuilder 5 on Mandrake 8

  http://community.borland.com/article/0,1410,27621,00.html

2002-Feb-05 12:39pm gyles19@visi.com

No Java 1.2.2 JVMs available support SMP kernels. So, you must install a 1.3.x JVM if you're using an SMB kernel, especially if your machine contains multiple processors, since this exercises SMB threading.

Early releases of IBM JDK 1.3.0 do NOT support SMP kernels. I'm told the most recent release does support SMP but I have not verified this myself.

Sun and Blackdown 1.3.0 both support SMP kernels.

Since JBuilder 4.0 for Linux is bundled with IBM's earlier 1.3.0, you must install an additional JVM for both JBuilder and your own Java applications to use.

  Since JBuilder 3.5 is bundled with Sun's 1.2.2, your only options are:

  1) Run JB35 on 1.3.0 (not a supported option, and not without problems) 
  2) Download JBuilder 4.0, and replace its bundled IBM JVM with either the
     latest IBM JVM, or with Sun or Blackdown 1.3.x, all of which support SMP.

I don't know if XFree86 goes deaf to keypresses when NumLock is on, or if it's adding some sort of key modifier bit to the keycode which applications aren't expecting to see.

2001-May-05 9:23am gyles19@visi.com

Your best bet is to download a newer JVM. Sun JDK 1.3.1 is known to work okay. I haven't heard from any one who replaced it with the most recent IBM 1.3.0 release but it's worth a try if you really want to stick with the IBM JVM.

To replace the bundled JDK, download Sun's 1.3.1 and install it somewhere on your machine. Then edit jbuilder4/bin/jdk.config and edit every statement which references something in the original jdk, and replace them with corresponding references to the new jdk.
2001-Jun-12 9:42pm gyles19@visi.com

Also, none of the F1-F12 function keys work. But oddly enough, the menu works, as do right-click context menus.

Pressing the numlock key to clear it solved the problem.

Bizarre!
2002-Jan-05 8:10am gyles19@visi.com

  tar -xzf jb4fndlinux.tar.gz

Basically, jbuilder is attempting to determine if config files exist in jbuilder4/lib/ext, so that it can then load them. The bug is that when there are no config files present, (a normal condition for JB Foundation, but not normal for a complete Enterprise installation) the function attempts to read the wildcard pattern as if it were the filename. IE it's trying to open and read filename "*.config", which naturally doesn't exist.

The ls command sets an error code based on the status of the match. The problem is that the version in /usr/ucb/bin sets a different error code than all the other versions.

The bug in the script is that it does not specify a specific version of ls, instead allowing the shell to find ls on the path. If the shell finds /usr/ucb/bin/ls, the script's test of the error code will be fooled because the error code isn't the expected value.

Workaround #1:
Remove /usr/ucb/bin from your PATH before running JBuilder.

Workaround #2:
Create a one-line shell script in jbuilder4/lib/ext/foo.config, and make that one line a shell comment like this:

  # foo workaround to fix a korn script problem

Save the file, and jbuilder should now launch without difficulty.

Workaround #3:
Delete the offending /usr/ucb/bin/ls binary.

2002-Jun-15 3:03pm gyles19@visi.com

Sun 1.3.1 is the only JVM known to work on Red Hat 7.1 (and other linux distrubibutions using the same or later kernel/glibcs.) Blackdown 1.3.1 FCS has just been released and may also work, but I have not heard of anything trying it yet (as of 7/13/01.)

Install Sun 1.3.1 SDK for Linux. Then edit jbuilder4/bin/jdk.config and change *all* paths to point to the corresponding bits of the new SDK.

See Also: JBuilder won't run on Red Hat 7.1/SuSe 7.x/Mandrake 8.x
2001-Jul-14 5:08pm gyles19@visi.com

    JBuilder's JVM dumps core
    No keys work
    Some special keys don't work (?, <, >, etc.)

To run the installer, you need to override its internal JDK with the new one, like this:

  ./install_linux LAX_VM /usr/local/java/jdk1.3.1/bin/java

Of course, replace the path above with the real to your java executable.
2001-Jul-13 10:48am gyles19@visi.com

  http://java.sun.com/j2se/1.3/jre/install-linux.html

If you're using any distribution other than Red Hat 6.2, pay close attention to the following section:

  http://java.sun.com/j2se/1.3/jre/install-linux.html#problems

Sun's JVM will use only IP Network sockets to access the display. So, you must set the DISPLAY variable to contain either the hostname, or its ip address.

So,

   export DISPLAY=tardis.aravox.com:0.0

works, but

   export DISPLAY=:0.0

will not.

Many login scripts use the latter by default because it's faster.

I use a custom JB launcher which, among other things, overrides Red Hat's default DISPLAY setting with one suitable for Java:

  export DISPLAY=`uname -n`:0.0

So, basically, every linux user who installs JBuilder on a recent distribution and/or anything with a 2.4 kernel or running KDE will have trouble with the installer and/or JBuilder's JDK.

JBCheck is a perl script I (Joi Ellis, TeamB) wrote using things I've learned while helping other users get JBuilder installed properly. It looks over your machine (any distribution) and looks for stuff known to cause problems for the intaller and for JBuilder's JDK. It then gives you suggestions (as current as I can make it) for fixing the problems it finds.

  http://www.visi.com/~gyles19/jbuilder/JBCheck

JBCheck makes no changes to your machine, and you don't need to be root to run it. I haven't seen a linux distribution yet that didn't have perl on it.

  
  perl ./JBCheck

   perl ./JBCheck -4

JBuilder 4/5/6 all seem to run perfectly fine on FreeBSD 4.5 with the native Java 1.3.1 (built from ports java/jdk13)

In my experience here, with jdk1.3.1p5, it worked well using the Tya JIT. With jdk1.3.1p6, I recomend not using any JIT as there appears to be thread-related bugs. Hopefully, the HotSpot JIT will be ported soon and we shall have much better performance. (see the freebsd-java mailing list)
2002-Apr-04 9:42am gyles19@visi.com

  ./per_install LAX_VM /path/to/jdk1.3.1/bin/java

Note that there is no = between LAX_VM and the path, and the path leads to the java command itself, not to the JDK's install root.

See also: What is JBCheck and what does it do? and JBuilder won't run on Red Hat 7.1/SuSe 7.x/Mandrake 8.x
2002-Jan-03 9:01am gyles19@visi.com

You can either:

  1) Remove the other jvm from your search path ("which java" should identify it, "whereis java" should list all of them)

  2) Launch the installer like this:

       ./doc_install LAX_VM /path/to/jbuilder6/jdk1.3.1/bin/java

The "LAX_VM java" parameters tells the installer to use the specified java command instead of the first one it detects on the search path.

2002-Feb-04 2:08pm gyles19@visi.com

  http://jcatki.dhs.org/imwheel/

Java uses X11's System cut buffer instead of the primary cut buffer like everything else in X. (Or vice versa, I forget which is which.)

XClipboard is one of the few apps that looks at all 3 X11 cut buffers.

Note, under JVM 1.2.2, occasionlly the JVM will dump core if you leave xclipboard up too long and attempt a new copy. JVM 1.3 doesn't do this. This can make JBuilder suddenly hang when you hit ^C to copy. The JVM is writing out a 200meg core file. Give it a few minutes and the window will close, and you can re-open JBuilder.

Moral of the story: If you're using JB Foundation 3.0 or JB 3.5, don't leave xclipboard running any longer than you need to, and safe often while it's running. This is a JVM 1.2.2 bug.

2000-Dec-21 4:14pm gyles19@visi.com

  (global-set-key "\M-\C-y" 'clipboard-yank) ; a yank that gets JBuilder's clipboard
  (global-set-key "\M-\C-w" 'clipboard-kill-ring-save) ; keep to JBuilder's clipboard
  ; M-C-w is, by default, the "append-next-kill" command .. but I've never used it.

you can use M-C-y to paste the JBuilder cut buffer and M-C-w to save to it (the way M-w does to the normal selection).
You will need to run "M-x eval-buffer" or restart emacs for the changes to take effect.
2001-Sep-10 5:00am mca-jbuilderfom@grantadesign.com

  http://developer.java.sun.com/developer/bugParade/bugs/4371923.html

  http://developer.java.sun.com/developer/bugParade/bugs/4390994.html

Here are some links to previous discussions:

http://www.mers.com/MERLIST/BORLAND/PUBLIC/JBUILDER/LINUX/1885.HTML http://www.mers.com/MERLIST/BORLAND/PUBLIC/JBUILDER/IDE/22805.HTML http://www.mers.com/MERLIST/BORLAND/PUBLIC/INSTALL/JBUILDER/1708.HTML http://www.mers.com/MERLIST/BORLAND/PUBLIC/JBUILDER/LINUX/1545.HTML

This may be of interest even though it's discussing Windows fonts:
http://www.multilingual.com/FMPro?-db=a&-token=now&-format=default.htm&-view

2001-Jan-22 7:47pm gyles19@visi.com

"Heiko Gottschling" wrote in message
news:93pmkb$i3p$02$1@news.t-online.com...

Hi,

here's what I did to deal with these positively putrefactive looks (as
someone else recently put it :-)) of the standard fonts. With this
configuration, JBuilder uses Microsoft Verdana as sans-serif font and
Courier New as fixed-width font - looks really great. Use at your own risk,
especially if you are unsure about license issues... Note that I only got
this to work with IBM's JDK (the one which comes bundled with JBuilder), it
seems not to work with Sun's.

1. I use XFree86 4.0 with its built-in support for true type fonts

2. Go to the fonts directory of JBuilder
(/opt/jbuilder4/jdk1.3/jre/lib/fonts) and type 'rm *'

3. Copy all (truetype!) fonts you want to use into that directory. Make
sure that your choice includes each a fixed-width, sans-serif and serif
font. (I used Courier New, Verdana, Times New Roman from the windows
directory, however there are plenty free truetype fonts if you don't want
to use these). Also, make sure to include the different 'makes' of a font,
like plain, italic, bold and bold italic (=4 files per font)

4. In the fonts directory, type 'ttmkfdir > fonts.dir'

5. Edit your font.properties file in /opt/jbuilder4/jdk1.3/jre/lib. I will
paste mine below, as said before it uses Times New Roman, Courier New and
Verdana, modify it to suit your needs. It will probably appear garbled, so
you might need to manually adjust some lines, but you'll figure out how to
do this :-) Valid entries are all those found in the fonts/fonts.dir file,
generated in step 4.

That's it, have fun
Heiko

--------------- font.properties ----------------

serif.0=-monotype-Times New Roman-medium-r-normal--*-%d-*-*-p-*-iso8859-1
serif.italic.0=-monotype-Times New Roman-medium-i-normal--*-%d-*-*-p-*-iso8859-1
serif.bold.0=-monotype-Times New Roman-bold-r-normal--*-%d-*-*-p-*-iso8859-1
serif.bolditalic.0=-monotype-Times New Roman-bold-i-normal--*-%d-*-*-p-*-iso8859-1
sansserif.0=-microsoft-Verdana-medium-r-normal--*-%d-*-*-p-*-iso8859-1
sansserif.italic.0=sansserif.0=-microsoft-Verdana-medium-i-normal--*-%d-*-*-p-*-iso8859-1
sansserif.bold.0=-microsoft-Verdana-bold-r-normal--*-%d-*-*-p-*-iso8859-1
sansserif.bolditalic.0=-microsoft-Verdana-bold-i-normal--*-%d-*-*-p-*-iso8859-1

monospaced.0=-monotype-courier new-medium-r-normal--*-%d-*-*-m-*-iso8859-1
monospaced.italic.0=-monotype-courier new-medium-i-normal--*-%d-*-*-m-*-iso8859-1
monospaced.bold.0=-monotype-courier new-bold-r-normal--*-%d-*-*-m-*-iso8859-1
monospaced.bolditalic.0=-monotype-courier new-bold-i-normal--*-%d-*-*-m-*-iso8859-1

dialog.0=-microsoft-Verdana-medium-r-normal--*-%d-*-*-p-*-iso8859-1
dialog.italic.0=-microsoft-Verdana-medium-i-normal--*-%d-*-*-p-*-iso8859-1
dialog.bold.0=-microsoft-Verdana-bold-r-normal--*-%d-*-*-p-*-iso8859-1
dialog.bolditalic.0=-microsoft-Verdana-bold-i-normal--*-%d-*-*-p-*-iso8859-1
dialoginput.0=-monotype-courier new-medium-r-normal--*-%d-*-*-m-*-iso8859-1
dialoginput.italic.0=-monotype-courier new-medium-i-normal--*-%d-*-*-m-*-iso8859-1
dialoginput.bold.0=-monotype-courier new-bold-r-normal--*-%d-*-*-m-*-iso8859-1
dialoginput.bolditalic.0=-monotype-courier new-bold-i-normal--*-%d-*-*-m-*-iso8859-1

alias.dialoginput=monospaced

# default char definition
default.char=02ff


fontcharset.serif.0=sun.io.CharToByteISO8859_1
fontcharset.serif.italic.0=sun.io.CharToByteISO8859_1
fontcharset.serif.bold.0=sun.io.CharToByteISO8859_1
fontcharset.serif.bolditalic.0=sun.io.CharToByteISO8859_1

fontcharset.sansserif.0=sun.io.CharToByteISO8859_1
fontcharset.sansserif.italic.0=sun.io.CharToByteISO8859_1
fontcharset.sansserif.bold.0=sun.io.CharToByteISO8859_1
fontcharset.sansserif.bolditalic.0=sun.io.CharToByteISO8859_1

fontcharset.monospaced.0=sun.io.CharToByteISO8859_1
fontcharset.monospaced.italic.0=sun.io.CharToByteISO8859_1
fontcharset.monospaced.bold.0=sun.io.CharToByteISO8859_1
fontcharset.monospaced.bolditalic.0=sun.io.CharToByteISO8859_1

fontcharset.dialog.0=sun.io.CharToByteISO8859_1
fontcharset.dialog.italic.0=sun.io.CharToByteISO8859_1
fontcharset.dialog.bold.0=sun.io.CharToByteISO8859_1
fontcharset.dialog.bolditalic.0=sun.io.CharToByteISO8859_1

fontcharset.dialoginput.0=sun.io.CharToByteISO8859_1
fontcharset.dialoginput.italic.0=sun.io.CharToByteISO8859_1
fontcharset.dialoginput.bold.0=sun.io.CharToByteISO8859_1
fontcharset.dialoginput.bolditalic.0=sun.io.CharToByteISO8859_1

From: "Gerald D. Anderson"

Hello all,

  Well, after playing and playing, and trashing my JB install a couple times, I have
found a way to do this.  The platform I used was RH7.0 (on i386/fully updated), using
the Ximian (gnome-helix) desktop (shouldn't matter though), and JBuilder 4 Pro.  I'll
try to give you a step x step idea of what I did to get this to work for me.  The
disclaimer for this would be that. . .it seems to be working for me so far, I'm not
seeing any instability, the fonts seem to scale fine, and they display and act
correctly.  However,  if you do display the little margin in the editor, that seems
to break, sort of, and while taking the many paths and spending many hours just
playing, I've trashed my JB environment a couple times.   So, if you are NOT
comfortable re-installing JB, or you're NOT comfortable using the utilities, editing
files, etc.  Do not try this.  I think it'll work for everybody, but absolutely no
guarantees.

Through out the document I use the directories that I installed stuff in, it may not
be the same for you, so pay attention and put your correct dirs in.

That being said, here goes. . .

1)  Move your ttf into your linux fs, I personally copied them into /usr/local/fonts
2) Make xfs (X Font Server) aware of the dir, and create a fonts.dir file for xfs
        # chkfontpath --add /usr/local/fonts
        # chkfontpath --list  [make sure your dir is listed]
        # ttmkfdir -d /usr/local/fonts  >> /usr/local/fonts/fonts.dir
                [will create a fonts.dir file for you, leave off append stuff to see
on stdout]
3)  Move these files to the java environment  [ # cp -arv /usr/local/fonts/*ttf
/usr/jbuilder4/jdk1.3/jre/lib/fonts/]  (do not overwrite fonts.dir)
4)  Append the fonts dir  [# cat /usr/local/fonts.dir >>
/usr/jbuilder4/jdk1.3/jre/lib/fonts/fonts.dir]
5)  Start up JBuilder and go to Tools/Editor Options/Display pane, when you get
there, you should see jbuilder suck in the new fonts.  Also, DO change your font here
to anything else
6)  Shutdown jbuilder
7)  examine the file ~username/.jbuilder4/user.properties, go down a bit and you
should see . . .
        a) a section of fixed_fonts
        then
        b) a section of known_fonts that contain your new fonts
        you can see an example of this at the bottom of this doc
8)  Make the fonts you want available in JBuilder editor into fixed_fonts, so say
I have
        editor.display;known_fonts.2=Century Schoolbook L
        And I want to make Century Schoolbook L a fixed font, I'd add
        editor.display;fixed_fonts.xx=Century Schoolbook L  [Where xx is the next
consecutive number in fixed_fonts, watch the sorting on this, it does 1, 10, 11, 12.
. .19, 2, 20 , 21. . .]
        I didn't remove the known_font entry for the fonts I used, so don't worry
about deleting the known entry, if you do RENUMBER THEM to keep 'em consecutive!!
9)  Once this is done, if you followed these directions, and IF it happens to work
for others you should be able to start jb and see the new fonts
        in the Tools/Editor Options/Display panel/ Font Family drop down.  They
should be perfectly usable at this point.

10)  I've noticed that SOME fonts will still cause Havoc, most "standardish" fonts
seem to be fine, I'm using MS Sans Serif, Arial, and MS Comic Sans without any
problem,
         I'd avoid any real weird fonts, laraeable fonts, etc.  But play, if you're
willing to risk it.

11)  Below is an annotated partial copy of my user.properties file so you can see the
changes in action, all comments in brackets [ ]  are mine and don't belong in the
file. . .

editor.display;fixed_fonts.1=Courier
editor.display;fixed_fonts.10=Lucida Console
editor.display;fixed_fonts.11=Marlett
editor.display;fixed_fonts.12=sshlinedraw
editor.display;fixed_fonts.13=Webdings
editor.display;fixed_fonts.14=Arial  [I added this, 13 was the last standard
fixed_font]
editor.display;fixed_fonts.15=Arial Narrow  [and this]
editor.display;fixed_fonts.16=Arial Black [same]
editor.display;fixed_fonts.17=Comic Sans MS  [same
editor.display;fixed_fonts.18=Microsoft Sans Serif [same]
editor.display;fixed_fonts.2=Courier 10 Pitch  [Notice the sorting on the numbers
here, careful of that]
editor.display;fixed_fonts.3=CourierThai
editor.display;fixed_fonts.4=DialogInput
editor.display;fixed_fonts.5=Lucida Sans Typewriter
editor.display;fixed_fonts.6=LuciduxMono
editor.display;fixed_fonts.7=Monospaced
editor.display;fixed_fonts.8=Nimbus Mono L
editor.display;fixed_fonts.9=Courier New
editor.display;font_family=Comic Sans MS  [This property is the name of the font
currently used, there's also editor.display;font_size=xx, if you change the size]
editor.display;known_fonts.1=Bitstream Charter  [All of these are the newly installed
ttf fonts, it's a long list, so I only pasted a few of them here, you should have the
idea by now]
editor.display;known_fonts.10=DialogInput
editor.display;known_fonts.11=Dingbats
editor.display;known_fonts.12=Lucida Bright
editor.display;known_fonts.13=Lucida Sans
editor.display;known_fonts.14=Lucida Sans Typewriter
editor.display;known_fonts.15=LuciduxMono
editor.display;known_fonts.16=LuciduxSans
editor.display;known_fonts.17=LuciduxSerif
editor.display;known_fonts.18=Monospaced
editor.display;known_fonts.19=Nimbus Mono L
editor.display;known_fonts.2=Century Schoolbook L
editor.display;known_fonts.20=Nimbus Roman No9 L
editor.display;known_fonts.21=Nimbus Sans L
editor.display;known_fonts.22=SansSerif
editor.display;known_fonts.23=Serif
editor.display;known_fonts.24=Standard Symbols L
editor.display;known_fonts.25=Thonburi
editor.display;known_fonts.26=URW Bookman L
editor.display;known_fonts.27=URW Chancery L
editor.display;known_fonts.28=URW Gothic L
editor.display;known_fonts.29=URW Palladio L


Well, that's my speil, it's not pretty, and there are risks involved, be especially
careful that you don't move any "weird" fonts to fixed_fonts, it can screw your jb
install.  Also, all of the known_fonts WILL show up in your printer font selection,
I think that's the only reason it really stores them, but who knows. . .

I really do hope this works for you guys, the default JVM fonts for linux/X are
completely unusable as a regular dev platform, this helps out tremendiously
(IMnsHO), I'd love to hear
about success and failures if anybody else tries this, if you fail, try to get as
much information as possible, I'd like to get this tight enough that perhaps Borland
will stick it on their
support site somewhere so our future brethren don't have to deal with this as we
have.  Though I will accept personal email, try to keep everything on the newsgroup
so others
can benefit, especially if you have problems!

Cynthia Jeness writes:


I installed j2sdk1.3.0 from Sun, but had a very similar error message.  In
order to fix this, I changed  the various symbol lines in the
font.properties file like this;


FROM:

  --symbol-medium-r-normal--*-%d-*-*p-*-adobe-fontspecific


TO:

  -urw-symbol-medium-r-normal--*-%d-*-*p-*-urw-fontspecific


This change was made based on examining the fonts that I actually have
available on my system which is a stock RedHat 7.0 plus necessry patches.
So basically, you need to make the font.properties match what you actually
have avaialble.

Blackdown has some information about Java Linux font handling and TrueType support in X11:


  http://www.blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux-6.html#ss6.4

  http://community.borland.com/article/0,1410,26583,00.html

See the following page for one fellow's instructions for making this work:

   http://mowgli.otago.ac.nz/dan/jb/

This page also contains workarounds for the -verbose message:

  OpenTool com.borland.jbuilder.node.JspFileNode failed to initialize

I've copied the Windows TTF fonts (Arial, Times New Roman, and Courier New) to the Linux jre/lib/fonts directory. Made the fonts.scale with the command ttmkfdir -o fonts.scale. This converts the TTF fonts to the linux font names. Then you have to create the fonts.dir with the command "mkfontdir" command. This will copy the fonts.scale to the fonts.dir file. Now comes the most stupid task: You have to edit the fonts.property file for your locale. This is very boring because you have to specify a name for each entry. i.E.

  sans.0=-monotype-Times New Roman-medium-r-normal--*-%d-*-*-p-*0-iso8859-1
  sans.1=....
   .
   .
   .
  dialog.0=....

You have to do this for each font and style which means italic, bold, etc.

[EDITOR'S NOTE: Copying the *.ttf files from Windows probably violates Microsoft's license, but if you're machine dual-boots Windows and Linux as mine does, I don't see how Microsoft can prevail if they sue you over it...]

2001-Mar-29 1:55pm gyles19@visi.com

  http://www.jguru.com/faq/view.jsp?EID=229424
 
  http://java.sun.com/products/java-media/2D/forDevelopers/java2dfaq.html

  http://java.sun.com/products/jdk/1.2/docs/guide/internat/fontprop.html

I installed j2sdk1.3.0 from Sun, but had a very similar error message. In order to fix this, I changed the various symbol lines in the font.properties file like this;

FROM:

  --symbol-medium-r-normal--*-%d-*-*p-*-adobe-fontspecific

TO:

  -urw-symbol-medium-r-normal--*-%d-*-*p-*-urw-fontspecific

This change was made based on examining the fonts that I actually have available on my system which is a stock RedHat 7.0 plus necessry patches. So basically, you need to make the font.properties match what you actually have avaialble.

2001-Mar-29 4:20pm gyles19@visi.com

  monospaced.bolditalic.0=-monotype-Courier New-bold-i-normal--0-0-0-0-m-0-iso8859-1

        COURBD.TTF -monotype-Courier New-bold-r-normal--0-0-0-0-m-0-iso8859-1

  # Serif font definition
  #
  serif.0=-b&h-lucidabright-medium-r-normal--*-%d-*-*-p-*-iso8859-1
  serif.1=-b&h-lucidabright-medium-r-normal--*-%d-*-*-p-*-iso8859-1
  #replace .1 font line if you have zapf fonts
  #serif.1=--zapf dingbats-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific
  serif.2=--symbol-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific

Your question implies your font.properties file replaces the * with 0. I don't think that's correct.

The fonts.dir file itself refers to them like this:

  LucidaBrightItalic.ttf        -b&h-lucidabright-medium-i-normal--0-0-0-0-p-0-iso8859-1
  LucidaBrightRegular.ttf        -b&h-lucidabright-medium-r-normal--0-0-0-0-p-0-iso8859-1

  $ su root -c "snice -12 -c X"

This will give your X11 server a serious priority boost and make the mouse and painting behavior much snappier.

This command was tested on Red Hat 6.2. Your mileage may vary. The snice command is an intelligent renice. If you don't have snice, you can do this:

  $ su root 
  $ ps -ef | grep X | more

Figure out the process id of your X process. On my machine it looks like this:

  100 S root     29158 29157  0  60   0    - 19675 do_sel Apr06 ?        03:37:27 X :0 -auth /home/joi/.Xauthority

The pid is the second number, in this example it's 29158. Now renice it:

  $ renice -12 29158

  29158: old priority 0, new priority -12

You have to be logged in as root to do this because only root can give a process a negative priority number. (The smaller the number, the higher the priority the process has.)
2001-May-03 11:19am gyles19@visi.com

On Linux 6.2, this package is: urw-fonts-2.0-4.rpm

2001-May-14 12:41pm gyles19@visi.com

Some advanced features of the debugger are disabled in Foundation.

Many of the debugger's features are unavailable when debugging class files which were compiled without debug information and/or have been obfuscated.

Verify that your Solaris platform has received all of the patches required by the JVMs you are using.

     http://www.java.sun.com/j2se/1.3/install-solaris-patches.html

  http://community.borland.com/article/0,1410,27307,00.html

  IBM 1.3.0
  Sun 1.3.0
  Blackdown 1.3.0
  Sun 1.3.1
  Blackdown 1.3.1

This appears to be purely a KDE2 issue, so it may be wise to avoid KDE2 if you can.
2001-Jul-25 10:39am gyles19@visi.com

  http://developer.java.sun.com/developer/bugParade/bugs/4392053.html

 LD_ASSUME_KERNEL=2.2.5

I'm running RedHat 7.1 with a 2.4.4 kernel and Sun's 1.3.1-rc2-b23 without having to set the LD_ASSUME_KERNEL variable to 2.2.5. It works with all of the Java apps that I use including JBuilder 4.0 Enterprise and the Java Plugin. The only exception to not setting the LD_ASSUME_KERNEL variable is Mozilla 0.9, as far as I know right now.
2001-Jul-02 4:15pm gyles19@visi.com

The problem:

  5026 pts/5    S      0:00 /home/alannon/lib/j2sdk1.3.1/bin/i386/native_threads/java
  5057 pts/5    Z      0:00 [java <defunct>]

 

 http://gamma.zerog.com/devnet_l/uT.jsp?page=kb/viewKB.jsp&itemID=14

I don't know if the bug is in KDE, libjsound.so, or in the JVM.

Workaround: Disable the audio.

  
  Tools | IDE Options | Audio
  clear the "Audio feedback enabled" item

  http://community.borland.com/article/0,1410,28122,00.html

  http://community.borland.com/article/0,1410,27814,00.html

If you're using NVidia's drivers, check their website for additional information, updates, etc.

General workarounds for this issue include:

  1) Switch from manufacturer-supplied XFree86 driver modules to XFree86's own modules
  2) Install more recent drivers
  3) Install more recent OpenGL libs for the current drivers
  4) Upgrade/downgrade XFree86 itself
  5) Switch to a different XFree86 driver module, ie change from 'nv' to 'svga'.

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

  #!/bin/bash
  export PRINTER=lp0
  export MPAGE="-Plp0"
  export LOG=/tmp/jbuilder5.log
  JBUILDER=/home/joi/jbuilder5/bin/jbuilder

  if [ $DISPLAY = ":0.0" ]; then
    export DISPLAY=`uname -n`:0.0
  fi

  unset JAVA_FONTS
  mv $LOG $LOG.prev >&/dev/null
  cd ~/jbproject; $JBUILDER -verbose $* 2>&1 | tee $LOG

You have to go to the "matched windows" preferences and add a new entry for the Jbuilder6 popups. Grab their "class" and their "name". Then specify that their state should be "ignored". This will prevent them from being minimized. I also told them to "focus-when-mapped" and "focus-mode=enter-only" but I'm not sure if those two settings are necessary.

2002-Jan-03 9:29am gyles19@visi.com

-Einar
2002-Feb-15 4:28am einarmr@tihlde.org

The error that appears when this problem occurs starts like this:

  *** OpenTool com.borland.jbuilder.JBuilderKeymap failed to initialize
  java.lang.StackOverflowError
      at java.lang.ClassLoader.findBootstrapClass(Native Method)
      at java.lang.ClassLoader.findBootstrapClass(ClassLoader.java:687)