This section discusses various aspects of running the JDK in detail.
$Id: 05-detail.sgml,v 1.3 1998/11/13 04:20:04 stevemw Exp $
From the README file:
The JDK now depends on having the X printing library, libXp installed with the rest of your X files. This is part of the most recent X11 distributions, so you'll need to upgrade (or, if you are daring, you can just extract the libXp.so* file from the upgrade package for your Linux distribution and install it by hand w/o upgrading everything else, although this is unlikely to work if your X libraries are substantially out of date).
The latest versions of the Blackdown JDK have their own built-in
loader (libdl.so) and libc.so, which will hopefully make them more
robust in most cases. Older versions of the JDK 1.1.5 (especially) are
much more sensitive. Take a look in
$JAVA_HOME/i386/green_threads/ to see these files.
(You may remove them if you feel they are a source of trouble to you.)
Karl Asha maintains a list of JDK-related library issues at:
http://www.blackdown.org/java-linux/docs/libraries.html.
In short, you need glibc-2.0.7 and glibc-devel-2.0.7
or higher on a glibc-based system such as RedHat 5.0 or Debian 2.0.
There are RPMs for these on RedHat Intel systems at
ftp://ftp.redhat.com/pub/redhat/current/updates/i386.
For a libc5 system, you need libc.so.5.44
or greater, along with a recent libdl.so. You can find these
at
ftp://tsx-11.mit.edu/pub/linux/packages/GCC.
For an in-depth discussion of this issue, see section What is glibc, and Why Does it Matter?.
Download the glibc and ld updates described under
http://www.redhat.com/support/docs/errata.html.
According to Sorin Lingureanu <sorin@tuiasi.ro>, JDK RPMs are to be found in ftp://ftp.redhat.com/pub/contrib. Levente Farkas has more information about running the Blackdown JDK on RedHat here: http://anna.inf.u-szeged.hu/java/java-rpm.html.
In addition to the general problems described in section
Environment Variables,
make sure that you don't have conflicting JDK_HOME,
JAVA_HOME, and CLASSPATH environment variables set
from scripts sourced from /etc/profile.d/ at login. This can
especially be a problem when trying multiple versions of the JDK in
succession.
Paul Reavis <preavis@partnersoft.com> has an excellent page with details at http://www.partnersoft.com/~reavis/java/Debian-JDK.html.
In JDK versions 1.1.5 through 1.1.6v2 we've seen a problem with
libc.so and libdl.so shipped with the JDK in
$JAVA_HOME/lib/i386/green_threads conflicting
with the system. Try removing these and then running Java.
Please help by posting your experiences with the Blackdown JDK on Slackware.
Check with http://nr.conexware.com/~zorzella/wine/FAQ2.htm to see if Luiz Otávio Lautenschläger Zorzella has additional information that applies to your platform.
You're welcome to contribute what you know to the FAQ.
Not really. The compilation flags may need to be different from what Javasoft recommends in the Solaris-oriented documentation.
Juergen Kreileder <kreilede@issan.cs.uni-dortmund.de>
points out that with the new Native Threads package, you should add
the -D_REENTRANT flag to your other options. Pointers to
more information about the native threads pack is available in
section
Is There a Native Threads Port of the Blackdown JDK?.
Keep in mind that there has been a known problem with all green threads implementations and the JVM Invocation API, discussed in section Is There a Problem with Green Threads and the JVM Invocation API?.
There have been reports of problems with C++
IOStreams using libstdc++-2.7.x. Note that
g++-2.8.1 and libstdc++-2.8.1 have been tested,
and seem to work fine for several users on RedHat 5.0.
Ed Roskos <roskos@bellatlantic.net> gives us these instructions for C JNI:
I've written a few shared libraries for use under both Linux and Solaris, and since a few people are curious about this, here goes:
- Make sure you have run javah. Plenty of documentation on this exists.
- You must first compile your C source files to object files, which end in ".o". Example:
gcc -fPIC -c -I<java-header-path> file1.c -o file1.o
You must replace<java-header-path>with the path to the include files for java-linux.- Create your library. This is not the same as creating an executable. Under Linux, use:
ld -shared file1.o -o libMyLib.so
If you have more thanfile1.o, just list them afterfile1.o.You can then, from Java, load your library as
System.loadLibrary("MyLib");Hope this helps.
Ed Roskos roskos@bellatlantic.net
According to Michael.Sinz@sinz.org,
As of JDK 1.1.6 v5, Kevin fixed the STDIO (System.in/System.out/System.err) problem. In JDK 1.1.7 V1 it was fixed even better for the poll() changes.Previous discussion of this problem is included for people on older JVMs.
Jon Wätte <hplus@zilker.net>, has a brief synopsis of green threads at http://www.zilker.net/~hplus/jvm.html. He states:
Sun's Java VM as running on Solaris [without the native threads package] used a user-level thread package named Green Threads. This is strictly a collaborative threading package; the JVM is one system process and only executes one Java code stream at a time.Bernhard Bablok <bablokb@lrz.uni-muenchen.de> has this suggestion:This is convenient for implementors, because special operations that required nobody else to touch sensitive data are intrinsically protected. As long as you don't relinquish the CPU (and block signals) you're in no danger.
If you do a [System.in.readLine()], the JVM will sit in the blocking input call until input is available; nothing else will happen in your program.
The System.in.readLine()method won't block other threads, if their priorities differ. My experience is, it doesn't matter which threads have a higher/lower priority. Priority shouldn't be much lower thanThread.NORM_PRIORITY(much lower means two lower on Linux).
Yes, there's a known problem with Javasoft's user-level threads package (called green threads) and the Invocation API because of the way it wraps system calls. See section What are Green Threads? for more information on green threads. Note that there is native thread support in the current JDK. See section Is There a Native Threads Port of the Blackdown JDK?.
Uncle George, Juergen Kreileder, and Bernd Kreimeier have encountered this problem, and through their discussion of it we have this list of references to consult for more information:
When building a Java-enabled application on Solaris and linking against the green threads version of libjava.so, you must defer system calls until after the call to JNI_CreateJavaVM. This is because the user-level threads package in libjava.so (green threads) defines its own system calls . . .And the JDK 1.1 Tutorial suggests that, "The first step toward getting this to work is always to link libjava.so into the executable *first*, even before libc.so . . ."
On June 21, 1998 Uncle George posted these paraphrased comments:
Actually, library calls are overridden, not system-calls. If you are savvy enough, you can call the system service yourself, and forget the library interface (i.e. instead of using select, try__select). But in doing so, the green threading . . . can be compromised, i.e. other threads won't be runnable until that service completes.The malloc()/free() bogus pointer messages are problems in trying to free a pointer twice, of which some "MALLOC" packages get terminally upset with . . .
You may also be interested in the discussion of native threads in section Is There a Native Threads Port of the Blackdown JDK?.
In addition to the information found here, you will certainly appreciate Dan Kegel's page, Fonts and Internationalization in Java found at http://www.alumni.caltech.edu/~dank/javafont.htm. You are encouraged to visit Javasoft's 1.1 discussion of this topic at http://www.javasoft.com/products/jdk/1.1/docs/guide/intl/fontprop.html, as well.
Please be aware that these FAQ entries are extremely sketchy at the moment. If you have additional information about making CJK (Chinese, Japanese, and Korean) code work well with Java on Linux, please tell the FAQ maintainer.
The following entries also relate more to situations that arise when you must settle on one set of libraries or the other, and you end up without being able to run some application or another because of unresolved symbols. Keep in mind that with their own builtin loader and libc, recent versions of the JDK shouldn't cause you to change your libraries at all.
Nozomi Matsumura <nmatsumu@can.bekkoame.ne.jp>
has a suggestion that at least applied to earlier, libc5
versions of the JDK, and may still work. It involves making
use of multi-byte character support provided in builds
of libX11.so with the Xsetlocale(3) call.
Matsumura-san points us at this fix provided by
Hiroshi Hisamatsu <hisama2@asahi.email.ne.jp>,
which is a small, shared library (liblocale.so) to explicitly
specify the Kanji locale. It is available from
http://www.asahi-net.or.jp/~nf6h-hsmt/jdk1.1.1-locale.tar.gz.
More detail on this is available in Japanese at
http://www.asahi-net.or.jp/~nf6h-hsmt/java.html. The
fix also involves adding the following lines to your .java_wrapper
file in $JAVA_HOME/bin:
LD_PRELOAD="$JAVA_HOME/lib/${ARCH}/${THREADS_TYPE}/liblocale.so"
export LD_PRELOAD
LANG to ja, and says that
ja_JP.{EUC,ujis} did not work.
In addition to the properties hacks mentioned above (see section
Libc5 Systems), the
inverse of what liblocale.so does is probably possible on
glibc-based systems, if there's a problem (with some other application)
at all. You may be able to simulate Xsetlocale(3) by wrapping
setlocale(3) with it. For example, libc5 versions of XFree86 (see
http://www.xfree86.org)
handle locale with the Xsetlocale(3)
call, but that changes under glibc to plain setlocale(3).
See the setlocale(3) manual page for more information.
On July 14th, 1998, Nozomi Matsumura <nmatsumu@can.bekkoame.ne.jp> also submitted this information acquired from Minori Takagaki <lennen@st.rim.or.jp>, who was able to input and display Kanji using TextComponent.
Takagaki was able to input directly using kinput2(XIM) or by cut&paste in Java applications and in appletviewer.
Takagaki's environment is:
font.properties.ja (to use X-TT fonts)liblocale.so (see the discussion of this above in
Libc5 Systems).java_wrapper
export LD_PRELOAD=liblocale.so export LANG=ja export DYN_JAVA=1 # to use libXm.so.2 from RH Motif2.1
$JAVA_HOME/bin/i686/green_threads/appletviewer
to use the dynamically linked java binary.But some probelms occur:
getText() function is O.K. but setText()
is not.getText() works correctly. Example: to input 'NIHONNGO
abcdef' when keying 'ab', 'NI' shows; when keying 'cd', 'HONN' shows, etc. . .