| ★ wanayoo — archive 1999 http://www.blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux-4.html | Nouvelle recherche | Portail wanayoo |
Discussion related to the plethora of Java APIs, only some of which are currently supported on Linux.
This section answers questions about APIs (application programming interfaces) supported by various Blackdown ports.
Last update:
$Id: blackdown-apis.sgml,v 1.4 2000/01/06 11:35:55 stevemw Exp $
Each Blackdown Java edition tries to support whatever were the core APIs for that version of Java. For those details, see section The Various Blackdown Java Editions for Linux. One of the biggest problems in Java 1.1 were threads, the interface to which consists of an API in and of itself.
Here are a few of the APIs which are getting a lot of attention. We'll add more information here when we have time.
For the latest status on a given API, check the Java-Linux Ports page at http://www.blackdown.org/java-linux/ports.html
This section discusses various issues with the java.lang.Thread API, an area with a reputation of portability problems for Java. Blackdown Java on Linux has had its share of gotchyas.
Last update:
$Id: threads.sgml,v 1.8 2000/01/11 06:50:23 stevemw Exp $
Yes, because the Linux kernel provides only a one to one mapping, the thread model doesn't scale as far as hybrid user and kernel space threading models such as LWPs on Solaris. However, one could argue that the Solaris model itself is excessive, and that reasonable applications should not expect to support thousands of threads at once.
For a rough idea of how many threads your version of the kernel can
support per JVM, consider the total number of tasks your kernel has
been compiled to handle, and what your hardware can actually support.
Here's a canned identifier search in the latest stable kernel for
NR_TASKS using the Linux Cross-Referencer:
http://lxr.linux.no/ident?i=NR_TASKS.
Yes, in both 1.1.7 and 1.2.x. Phill Edwards added native threads
support to 1.1.7 support; the 1.1.8 native threads implementation has
been back-ported from 1.2.2. See section
When do I need extra *native* binaries?
if you're wondering which distribution requires you to unpack
j*-native.tar.* files.
You can find more information about related command-line options and environment variables in the http://www.blackdown.org/java-linux/docs/faq/README/1.1/THREADS-117v1a and http://www.blackdown.org/java-linux/docs/faq/README/1.2/README.linux files that accompany binary Blackdown Java distributions.
Green threads use some magic with jmp_bufs, stack
pointers, the program counter, and some other hocus pocus to schedule
different instruction streams. This gives the practical effect of
multi-threading with some caveats about signals and how they're
handled across longjmp()s. See the discussion of
native threads in section
Is there a native threads port of Blackdown Java?.
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. Note that there is native thread support in the current JDK. See section Is there a native threads port of Blackdown Java?.
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 <gatgul@voicenet.com> 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 Blackdown Java?
See the Linux Threads Library page at http://pauillac.inria.fr/~xleroy/linuxthreads/ for FAQs, documentation, and source for the native threads API used in Blackdown Java.
This section discusses Blackdown support for Jini, a distributed API intended for "ubiquitous computing" with Java-enabled devices.
Last update:
$Id: jini.sgml,v 1.2 1999/12/31 08:36:19 stevemw Exp $
Yes, but you need to be using Java 2, preferably a recent build.
On September nine, 1999, Blackdown developer Cees de Groot <cg@cdegroot.com> had this to say:
I'm using it and it works. What's more to say?
If you are having problems, check three things:
This section describes Blackdown support for the Internet browser "plugin" for adding a given JVM to Netscape.
Last update:
$Id: browser-plugin.sgml,v 1.3 2000/01/06 11:35:55 stevemw Exp $
Blackdown now has access to the source for the 1.2 version of the plugin, has made an initial RC (release candidate), and intends to continue to develop it. See the Java-Linux Ports page at http://www.blackdown.org/java-linux/ports.html for its current status.
See http://www.javasoft.com/products/plugin/.
There is a FAQ page at Javasoft, as well: http://www.javasoft.com/products/plugin/plugin.faq.html.
Amit Patel <amitp@theory.stanford.edu>, who has been working on HTTP proxies answers:
The Java Plug-in requires that web page authors make changes to their existing HTML code if they wish to have their JDK 1.1-based applets run using the Java Plug-in, rather than the browser's default Java runtime. While the changes are not trivial, they are not overly complex either.
To make this process easy for web page authors, Sun provides the Java Plug-in HTML Converter, free of charge, to automate this process. In addition, Sun has provided a detailed specification outlining the HTML changes required to use the Java Plug-in, and how web page authors can implement them "by hand". The Java Plug-in HTML Converter can be downloaded from the HTML Converter download page. For the HTML specification, see the Java Plug-in HTML Specification.
Again, Amit Patel <amitp@theory.stanford.edu>, answers:
The Java Plug-in HTML Converter provides both a default template (default.tpl), and three supplementary templates. These supplementary templates allow web page authors to more explicitly target the browsers and platforms used in their environment when modifying their pages using the Java Plug-in HTML Converter:
This section describes Blackdown support for accessing native code through the JNI API.
Last update:
$Id: native-interfaces.sgml,v 1.9 2000/01/11 06:50:21 stevemw Exp $
This section is under construction. Recent mailing list traffic would indicate that there are major C library transition issues affecting JNI portability and general functionality.
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 Blackdown Java?.
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.
We've provided a couple of rudimentary examples (including Makefiles)
below. They all assume that you have the JDK installed in
/usr/local/java/jdk. These worked with both JDK 1.1.8
and 1.2.2RC3 on RedHat 6.1 i386, with the
egcs-1.1.2-24 and egcs-c++-1.1.2-24 packages
installed.
Examples like these can be found in chapter two, Getting Started of Sheng Liang's The Java Native Interface: Programmer's Guide and Specification in the Java Series published by Addison Wesley in 1999 (ISBN 0201325772). You can find more elaborate examples at the book's web page here: http://java.sun.com/docs/books/jni/.
When you run java_g, the environment variable
$DEBUG_PROG can be used to specify a debugger to
use. For more about this topic, pick up a copy of Rob Gordon's
Essential JNI published in 1998 by
Prentice Hall PTR, ISBN
0-13-679895-0 and look at chapter 14, "Debugging Native Methods."
This section describes Blackdown support for the Java 3D API.
Last update:
$Id: 3d.sgml,v 1.1.1.1 1999/12/27 06:13:31 stevemw Exp $
Although the information in the FAQ may be outdated by the time you read it, it was still under development at the time of this writing.
Java 3D requires Java 2. Second, Blackdown has only built it for i386 (at the moment). Work continues. See the JDK 1.2 Status Page at http://www.blackdown.org/java-linux/jdk1.2-status/ for the latest, as usual.
To read more about Java 3D, see Sun's website at: http://www.javasoft.com/products/java-media/3D/index.html.
Kenneth W Flynn <flynnk@rpi.edu> posted this explanation:
3D installation under RedHat 5.2
java3d1_1_1pre-v1-linux-sdk_tar.bz2..../Mesa-3.0/lib to /usr/lib
or your favorite library location that ldconfig can find.ldconfig -v to make those libraries available.cp URW/* /usr/lib/X11/fonts/URW/You also need to update your XF86Config file's font section to match the one shown on the webpage; then restart X.
ln -s /usr/lib/libstdc++.so.2.8.0 /usr/lib/libstdc++-libc6.0-1.so.2
Discussion of Blackdown support for Java Platform Debugging Architecture (JPDA) API, as well as general debugging issues for Java on Linux.
Last update:
$Id: jpda.sgml,v 1.3 2000/01/06 11:35:56 stevemw Exp $
Basic JPDA support has been added with 1.2.2. With RC4, full support will be available, including JPDW (the Java debug wire protocol) and JDI (the Java virtual machine debug interface). We hope to add more documentation specific to Linux about this soon, but for now, please visit Sun's site at http://www.javasoft.com/products/jpda/.
See section How can I step into native methods used by the JVM?, which may offer some help.
This section describes Blackdown support for the JMF, or Java Media Framework API.
Last update:
$Id: jmf.sgml,v 1.1.1.1 1999/12/27 06:13:32 stevemw Exp $
Blackdown developers have been working with Sun to stay current with JMF sources, We hope to add more information about this soon, but for now, please see
http://www.blackdown.org/java-linux/jdk1.2-status/ for more information.
To learn more about the JMF in general, Sun's site is at: http://www.javasoft.com/products/java-media/jmf/.
On September eight, 1999, Amith Yamasani <amith@eng.sun.com> had this to say:
You can use the JMF1.1 All-Java version on Linux. There is no separate Linux build and the Solaris build cannot be used on Linux. The all-java version does not support some formats that require native libraries (such as Indeo, MPEG and so on). Please see the JMF 1.1 documentation page for a list of supported content-types and codecs.
You can also try out the JMF 2.0 beta release (all-java) version. It has support for more codecs than JMF 1.1 and includes a pure java MP3 decoder.
[Amith claims you can obtain these files at http://java.sun.com/products/java-media/jmf/.]