| ★ wanayoo — archive 1999 http://www.blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux-7.html | Nouvelle recherche | Portail wanayoo |
This section covers random questions that didn't fit into the other categories.
While the majority of this FAQ tries to focus on Blackdown Java itself, we attempt to answer a few Linux-specific questions here. There are many better places to learn about Linux than this FAQ, however.
Last update:
$Id: general-linux.sgml,v 1.3 2000/01/07 05:47:57 stevemw Exp $
Here's a list of good places to start:
The UNIX "libc" is the core set of functions to which most utility and
application code links. You can see references to libc in the
intro(3) manual page. For your information, functions
described in section two (see intro(2)) of the manual are all
inside the kernel, whereas section three describes those which may be
standard, but are stored in separate libraries. To view these pages,
make sure your core manual pages are installed, and type man 3
intro, for example.
In order to save disk space and memory, modern operating systems like
Linux have taken to using "shared" libraries that don't move their
contents into code which links to them during the build process.
Although there is a /usr/lib/libc.a, most production code is
linked to /usr/lib/libc.so, which is typically a link-editor
script for selecting the actual libc.so (shared object) archive.
In short, lots of programs on your system share code out of one or
more files as they execute. To see what shared code an executable
needs, there is an optional Linux utility named ldd(1). If
it's on your system, you can type ldd PROGRAM to see its
shared libraries.
Here's an example:
$ ldd /bin/ls
libc.so.6 => /lib/libc.so.6 (0x40003000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
The new library is now called "glibc" because it's a library common across Linux and HURD, and enjoys a broad base of GNU developer contributions. (I don't know how much of the earlier Linux libc software was derived from GNU libc, which has been around for quite a while on its own, I think.)
For more information on GNU libc, see See http://www.gnu.org/software/libc/libc.html.
Since C is central to the history and development of UNIX and Linux, you might enjoy the links found on http://www.lysator.liu.se/c/ as well.
This section contains replies to a selected list of general questions about Java.
Last update:
$Id: general-java.sgml,v 1.12 2000/01/07 05:47:56 stevemw Exp $
Java is an imperative, object-oriented language from Sun Microsystems with a syntax similar to C. Because it supports classes, it is sometimes compared to the C++ language. Java is also compared to Smalltalk in part because they are both interpreted and require all user-defined types to be objects.
Java was first developed for handheld devices in the early 1990s. After indicating that he wanted move on out of frustration with the company's unfocused technical direction, Patrick Naughton changed his mind when CEO Scott McNealy offered to team him up with a variety of talented Sun people to create a new computing environment. They would have mixed results, but Java survived. For more on Java's dramatic origins, see section Why was the Java language created?.
One of Java's most attractive features is the common interface it tries to provide the programmer to a given host platform. Java classes are normally compiled into a format which will run on an abstract CPU known as the "Java Virtual Machine" (JVM). The execution of this "Java Byte Code" on the JVM is then simulated by a byte code interpreter running on the target system. However, JVMs have also been implemented in hardware Sun advertises as Java Processors. Berkeley's CPU Info Center website has more information about Java chips.
Some JVM implementations, in order to run faster, use a technique known as "Just-In Time compilation" (JIT). In a JIT, byte codes are translated to native machine code in a controlled fashion when they are first encountered, and then executed natively on a host processor. When the cost of compilation is low and the byte code is executed many times during Java program execution, JIT compilation can produce dramatic performance improvements. For portability, Java is normally not compiled to native code and executed directly by the host processor. (See section Just In Time Compilers for Blackdown Java for questions about JITs available to this implementation.)
The "architecture-neutrality" of Java and its standard windowing environment (called AWT) allow for a fair degree of platform independence. Sun markets Java for its "write once, run anywhere" (or "WORA") capability, but those developing serious applications with Java know that one must still test on targeted platforms. For example, moving an application between SPARC/Solaris and i396/Linux may reveal surprising differences despite the similarities of both platforms. Furthermore, Internet browsers such as Internet Explorer and Netscape Navigator implement Java differently enough so that in practice, considerable development effort must ensue in order to provide consistency to the user.
Java attempts to be a language of choice for developing network-based applications. It is multi-threaded or "concurrent," and much of its class library is thread-safe. Thread support is intended in part to help Java handle networking tasks. One of the design goals for Java was that it could provide a safer, more secure execution environment for code in distributed computing applications running in conditions as hostile as the Internet.
The JVM can be configured such that only a safer subset of Java instructions can be executed. "Applets," which are intended for use in a web browser, use what is known as a sandbox. The safety of individual byte codes is checked just once, at class load time. This ability to use a "verifier" on the byte code can improve the performance of sandboxed code without sacrificing safety. A sandboxed environment also attempts to provide more security for networked applications by limiting access to certain resources host platform resources. Moreover, Java does not allow direct memory access except through its Native Interface API (JNI), which is restricted for applets.
Rather than burden the programmer with the task of managing memory, Java uses "garbage collection" (GC) to automatically reclaim storage which is no longer being used by an application. This works well in practice: memory "leaks" (where the system refuses to reuse a chunk of memory which the application has finished using) are rare. Allocation efficiency is high. Unfortunately, garbage collection can sometimes cause problems in interactive or real-time applications: many GC implementations do their work in large batches, which can lead to long pauses at unexpected times. Unfortunately, current techniques for avoiding this problem typically lead to less efficient GC.
Finally, Java's support for modularity is quite good. A simple but reasonably effective package facility has been used to create a powerful class library that most Java programs use heavily. Access control to packages and classes is provided by mechanisms which are fairly easy to use, yet quite effective.
For a more detailed look at the language, please see The Java Language Environment: a White Paper at http://java.sun.com/docs/white/langenv/ by James Gosling and Henry McGilton in May 1996. You may want to go to a less flowery description of the Java language found in The Java Language Specification by James Gosling, Bill Joy, and Guy Steele at http://www.javasoft.com/docs/books/jls/. You can get an inside view of the JVM in The Java Virtual Machine Specification by Tim Lindholm and Frank Yellin at http://www.javasoft.com/docs/books/vmspec/. For questions about Java security, see the links in section Is Java secure?.
In January of 1991, Patrick Naughton, James Gosling, Mike Sheridan, and Sun founder Andy Bechtolsheim went to stay with Bill Joy in Aspen to brainstorm. Together, they felt that a dramatic change was needed in the direction Sun had been taking with hardware and software, and CEO Scott McNealy had given them permission to work on a secret project to develop a new product. They wanted to make a revolutionary wireless, hand-held platform. While there, they realized that they needed a programming environment to succeed. Bill had talked about a language environment using C++ which he had envisioned for a 64-bit OS called Spring at Sun Labs. Instead, James would take a different direction.
For 18 months, Ed Frank and Mike Sheridan led the resulting project known as "Green." Their team included Chris Warth, Craig Forrest, Jonathan Payne, Jim Graham, Wayne Rosing, Joe Palrang, and Chuck Clanton. Among the results of this frantic effort would include the Oak programming language, for which James takes credit. Given Bill Joy's interest in C++ for Spring, it's no accident that the two languages have several common features.
The remaining history of the Green project is interesting, but suffice it to say that Oak, which evolved into Java, survived when Green failed to achieve an immediate customer. Despite Green's mixed results, Java would become very important to Sun. Since Java's developers were already interested in integrating it into Web-based applications, Webrunner (the first Java web browser) inspired developers to create the first Java applet in early 1994.
Source: The Java Handbook, written by Patrick Naughton and published in 1996 by McGraw-Hill (ISBN 0-07-882199-1).
Here are a number of excellent starting points.
It has features that make it a candidate for being more secure than other choices. To read more about Java security, see the page Java Security FAQ: the Unofficial Answers from the Princeton Secure Internet Programming Team at http://www.cs.princeton.edu/sip/faq/java-faq.php3.
This section discusses problems with displaying and inputting Chinese, Japanese, and Korean language characters in Blackdown Java applications.
Last update:
$Id: cjk.sgml,v 1.3 1999/12/31 08:36:16 stevemw Exp $
Yes, but the information we have to offer on this is sketchy.
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 sparse. 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 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 problems 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. . .Editor's note: see section TrueType Support in X11.
Questions about Blackdown's Y2K readiness or lack of it.
Last update:
$Id: y2k.sgml,v 1.2 1999/12/30 12:01:41 stevemw Exp $
Blackdown Java hasn't been y2k-tested, but according to Scott Hutinger <srh@www.mprojects.wiu.edu>, the current JDK 1.2.2 RC included some date patches from one of our Sun Liasons. For now, please see http://java.sun.com/features/1999/08/y2k.html for more information.
You're welcome to contribute what you know to the FAQ.