| ★ wanayoo — archive 1999 http://blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux-6.html | Nouvelle recherche | Portail wanayoo |
This section attempts to answer your initial questions when you're trying to solve problems with Blackdown Java.
This section offers help for people trying to help themselves deal with Blackdown Java when it's broken.
Last update:
$Id: solving.sgml,v 1.8 2000/01/11 06:50:22 stevemw Exp $
CLASSPATH.:$JAVA_HOME/lib/classes.zip.PATH$JAVA_HOME/bin -- ahead of /usr/bin
where the
Kaffe JVM
often lives, please!JAVA_HOMEJDK_HOMEIf you have the Kaffe JVM installed, you may see something like this:
javac HelloWorld.java
and seeing this message:
Failed to open object 'HelloWorld/java'
Other people have reported error messages such as these:
$ javac
Failed to locate native library in path:
/usr/lib
Aborting.
Daniele Lugli <danlugli@tin.it> reports:
...The javac which was giving the problem was /usr/bin/javac, that is the kaffe javac. Now that I moved $JAVA_HOME/bin ahead in my $PATH, both javac and java work, and I see a wonderful "Hello, World!".Always check for conflicting environment variable problems. For details on how to do this, see section Environment Variables.
A very common cause for problems with Kaffe is having
/usr/bin in your path ahead of
$JAVA_HOME/bin.
Rich McClellan <richmc@entropy.ucsc.edu> reports that running the Blackdown JDK 1.1.5v7libc works better than the glibc version, and forwards this advice from Alexander V. Konstantinou <akonstan@cs.columbia.edu>:
The problem is related to naming in /etc/hosts. This is a known Java problem in picking up the right name for the interface. Change the localhost name to your real machine name. This may cause problems with talk though ...
Slackware JVM 1.1.x users have found that removing the libdl.so.*
and libc.so.* files
from $JAVA_HOME/lib/i386/green_threads takes care of
this problem. We don't know what causes it yet, though.
You have two strong candidates as causes for this problem.
java -ms16m -mx64m ....
From the JDK documentation:
-ms<number> set the initial Java heap size -mx<number> set the maximum Java heap size
free command
can help you there. See the manual page for free(1). For the
current minimum system requirements, see the discussion of them
in section
What System Configuration do I Need to Run the JDK?.See the manual pages for swapon(8) and mkswap(8).
Karl Asha has setup a Jitterbug problem-report form at http://www.blackdown.org/cgi-bin/jdk. Please report problems by filling this in as best you can. There are some guidelines for this in section What Should I Report?.
Before submitting a bug, you may be able to help by visiting Javasoft's Bug Parade at http://developer.java.sun.com/developer/bugParade/bugs/ and checking for related problems. If you mention a bug from a JDC bug ID in your problem report, it can help Blackdown JDK developers. At this time, you will have to join the JDC in order to search this database.
As usual, feel free to open a discussion about your problems on the java-linux@java.blackdown.org mailing list.
Although it may not seem so, solving Linux JDK problems can sometimes be difficult because of the large variation of systems that are in use. Please do your best when reporting a bug to tell us all about your system, the code you're running, and anything else that can help. Here's a checklist of items to mention.
java -version to see.ldconfig -D 2>&1 | grep libc | tail -1 to see.ldconfig -D 2>&1 | grep ld | tail -1 to see.xdpyinfo | grep 'release number' to see.uname -r to see.Try running the JDK java, appletviewer, and javac wrapper scripts like this:
$ sh -x $JAVA_HOME/bin/java -verbose -verbosegc -cs -verify ...
$ strace -f -s 256 $JAVA_HOME/bin/java ...
We've created a troubleshooting information collection script that you can download from http://www.blackdown.org/java-linux/docs/faq/tools/jsysinfo.sh and follow the instructions at the top of it. Read the output carefully; it's full of hints that can help you solve the problem on your own.
For serious troubleshooters, see the advice given in section How can I step into native methods used by the JVM?.
This section covers questions about Blackdown Java's interaction with environment variables on the system.
Last update:
$Id: envs.sgml,v 1.4 1999/12/31 16:16:05 kreilede Exp $
On June 7th, 1999 Nelson Minar <nelson@media.mit.edu> put this list together.
The following is documentation for environment variables the JDK supports. Note, this is not a comprehensive document for all variables: generic variables like LD_LIBRARY_PATH and LOCALE are not mentioned unless they have Java-specific meanings.
1.1 refers to 1.1.7_v3a, 1.2 refers to 1.2pre-v1. The Blackdown ports support both Green threads and native threads - some variables are only valid in one of the two.
Variables with Blackdown specific behaviour Java 1.1 and Java 1.2:
Variable Settings
-------- --------
THREADS_FLAG "green" for green threads
"native" for native threads
Variables with Blackdown specific behaviour Java 1.1 and Java 1.2, green threads only:
Variable Settings
-------- --------
JDK_NO_KERNEL_FIX "true" to remove fix for kernel accept() bug
DO_NOT_FREE Turn off freeing memory entirely.
DO_NOT_CHECK_MEM If set, removes some checks for double-freed memory
bugs associated with AWT. Dangerous, but slightly
faster.
Variables with Blackdown specific behavior Java <= 1.1.7v3 only, all threading models:
Variable Settings
-------- --------
NS_JAVA If set, runs a JDK with no AWT or X11. Starts up
faster, no graphics. See also DISPLAY
DISPLAY If unset, acts like NS_JAVA is set (1.1.7v3 only).
See also man page X(1)
DYN_JAVA If set, Motif is dynamically linked instead of
using the Motif statically linked into the JDK bins.
Generic JDK variables, Java 1.1 and Java 1.2:
Variable Settings
-------- --------
CLASSPATH See JDK documentation
JAVA_COMPILER If set to "tya", then "libtya.so" will be used as
a JIT compiler if it is installed correctly. If
set to "none", no JIT will be used.
Java 1.1 uses no JIT if unset
Java 1.2 on i386 uses the Sun JIT (sunwjit) if unset
This section discusses display problems and their workarounds with Blackdown Java.
Last update:
$Id: x11.sgml,v 1.1.1.1 1999/12/27 06:13:33 stevemw Exp $
Michael Sinz of the Blackdown team explains:
In versions of the JDK 1.1.x that predate JDK 1.1.7v3 you need to set the NS_JAVA environment variable.
As of JDK 1.1.7v3, the JDK will also support noticing that you do not have the DISPLAY environment set and thus will use the NS_JAVA setting.
This section discusses font problems and their workarounds on Blackdown Java.
Last update:
$Id: fonts.sgml,v 1.5 2000/01/16 00:44:37 stevemw Exp $
They're needed for Java2D. Also, UNICODE (see http://www.unicode.org) mapping is only correct with TrueType fonts.
Blackdown developer Juergen Kreileder <kreilede@issan.cs.uni-dortmund.de> answers:
I've asked some time ago and was told that it is not possible because of copyright. The copyright is somewhat strange, http://www.softseek.com/Graphics_and_Drawing/Fonts/Fonts/Review_17322_index.html says:
The font is technically not freeware -- Microsoft has secured from The Monotype Corporation the rights to distribute these fonts from their Web site at no cost.The MS site is http://www.microsoft.com/typography/fontpack/default.htm. So we would have to ask Monotype. The fonts and the EULA are available from http://www.agfamonotype.com/soft_dev/ (click on Euro).
Juergen Kreileder <kreilede@issan.cs.uni-dortmund.de> answers again:
The problem is that XFree86 doesn't support TrueType fonts yet, this will get better with XFree 4.0.
Juergen continued by saying that upcoming releases of Java 2 from Blackdown
would have improved tweaks to fonts.properties to help them
to work more smoothly.
On January 5th, 2000, Juergen explains further about the missing zapf dingbats and symbol problem:
The problem is that the URW fonts are available with two different foundries: urw and abode. The two foundries use different family names for the fonts too. The reason why we currently use the urw foundry is that the abode foundry uses ambiguous family names, this may result in using the symbol fonts from {75,100}dpi instead of the symbol font from urw, this gives a bad font display.So the best way to use the urw fonts with the JDK currently is to use a fonts.dir file with urw foundry and a font.alias file with the adobe foundry. Doing it vice versa is not possible as the JDK currently can't deal with font.alias files. [I've attached the fonts.* files from the Debian gsfonts-x11 package.]
Also, it's advisable to make the fonts available through the Xserver directly (i.e. do not use a font server for the urw fonts). This allows the JDK to get direct access to the font files.
The general consensus among experienced Java Linux developers is that to not warn users of an actual deficiency would be a mistake. Simple workarounds exist, however.
Yes, and FAQ editor's note: you can also find more information about displaying TrueType on X11 from http://www.darmstadt.gmd.de/~pommnitz/TrueType/xfsft.html and ftp://ftp.xfree86.org/pub/XFree86/current/doc/RELNOTES or go to the XFree86 Home Page at http://www.xfree86.org/ and follow the links to Current Release.
See http://www.linuxdoc.org/HOWTO/XWindow-User-HOWTO.html.
This section discusses problems with running Blackdown Java with X11 window managers. Also see section Blackdown Java and X11.
Last update:
$Id: window-managers.sgml,v 1.3 1999/12/31 08:36:21 stevemw Exp $
Since AWT is (for better or worse) based on Motif, a Motif-like window-manager may be less likely to have problems.
In general, window managers are a problem for UNIX users because each has a varying degree of ICCCM (Inter-Client Communication Conventions Manual) standards compliance. Moreover, window managers come with a range of features and bugs.
Please to contribute what you know about your window manager and running Blackdown graphical Java to the FAQ.
See Christophe Tronche's conversion of the 2.0 version of this document by David Rosenthal at http://tronche.com/gui/x/icccm/.
One discussion of the issues is found at the GNOME developer site: http://developer.gnome.org/doc/standards/wm/book1.html.
This section discusses various performance issues with Blackdown Java, which has been one of the more active threads on the mailing list. Performance has traditionally been limited by CPU speed, memory, and Linux's one-to-one kernel thread model.
Last update:
$Id: performance.sgml,v 1.2 2000/01/06 11:35:56 stevemw Exp $
Stay tuned for more. Meanwhile, these links should be useful:
Nathan Meyers <nmeyers@javalinux.net> suggests this approach:
My recommendation is to stop trying to make sense of the output from top and ps, and go to an unambiguous source. Take a look at the contents of /proc/<pid>/status, where <pid> is the process ID. This will, at any instant you examine it, give you (among other things) total current VM usage and RSS.