JavaTM 2, Standard Edition, v. 1.3.1_02a
for Caldera® OpenLinux®
and Open UNIX® 8 (with LKP) Operating Systems
This is a product built for Linux. Support on Open UNIX 8 is by way of, and requires installation of, Open UNIX 8's Linux Kernel Personality (LKP) feature.
The Java 2 Standard Edition contains both the Java 2 Runtime Environment, which allows Caldera end users to run Java applets and applications on these Caldera operating systems, and the Java 2 Software Development Kit (J2SDK), which enables Caldera OEMs, ISVs, and end users to develop Java applets and applications that conform to the Java 2 Core API.
This product is hereafter referred to as either "J2SE 1.3.1 for Caldera Linux" or "J2SDK 1.3.1 for Caldera Linux", depending upon which context the reference occurs in.
J2SE 1.3.1 for Caldera Linux is a full implementation of the Sun MicrosystemsTM Java 2 Platform - the technology and environment described in the SunTM specifications of the Java 2 Platform, Standard Edition, v. 1.3.1_02 FCS. (The _02 suffix indicates the patch level of the Sun J2SE that J2SE 1.3.1 for Caldera Linux corresponds to.)
J2SE 1.3.1 for Caldera Linux also incorporates the Java 2 Platform, Standard Edition, v. 1.3.1_02aFCS implementation from the Blackdown project (http://www.blackdown.org).
Caldera International, Inc. gratefully acknowledges the contribution of the Blackdown Group in providing and ensuring the continued availability of the latest Java Software Development Kit and Java Runtime Environment releases for the Linux community, including the Linux on Intel platform.
These Release Notes refer to this product as being for "Caldera Linux" to distinguish the operating systems supported by this Java implementation from the existing Caldera UNIX® operating systems. There is a separate Java 2 Standard Edition implementation available for Caldera UNIX operating systems.
| Software: |
Supported Caldera platforms:
|
| RAM: | 64 MB |
| Disk Space: | Minimum 80 MB |
J2SE 1.3.1 for Caldera Linux includes improvements in reliability, performance, and functionality, compared to the previous J2SE 1.3.0 for Caldera Linux.
See the Sun J2SE 1.3.1 Release Notes at http://java.sun.com/j2se/1.3/relnotes.html for the changes Sun has made in this release.
For a complete list of new Sun features in Java 2 Standard Edition version 1.3, visit http://java.sun.com/j2se/1.3/docs/relnotes/features.html. (Potential compatibility problems between this release and J2SDK 1.2.2 and earlier Java releases are described at http://java.sun.com/j2se/1.3/compatibility.html.)
The following changes specific to the Caldera Linux implementation have been made, relative to the previous J2SE 1.3.0 for Caldera Linux:
/usr/share/java to automatically include in the
CLASSPATH, but such jar files are included at
the end of the classpath, rather than at the beginning as before.
/usr/lib/java to automatically
include in the LD_LIBRARY_PATH.
jdk package.
jdk-debug package is available, which includes
_g debugging versions of the Java commands and libraries.
| Approx. Size | ||
jre | 15 MB | Contains all that is necessary to execute Java applications: Java Virtual Machine (JVM), HotSpot client and server run-time compilers, and all J2SE class libraries and tools. Contains man pages for J2SE 1.3.1 tools. |
jdk | 11 MB | Contains the necessary command-line tools to build Java applications. Contains the appletviewer tools to view applets. Contains the necessary header files to build native code. Also contains demo examples of Java 2 applets, Swing programs, and native code. Contains man pages for J2SDK 1.3.1 tools. |
jdk-debug | 18 MB |
Contains debugging versions (_g-suffixed)
of many of the J2SE and J2SDK commands and libraries.
These are versions that were compiled with debugging on and assertion
checking on, rather than for optimization.
They
are useful when you are troubleshooting a problem within native code,
or within the Java Virtual Machine itself.
|
An additional purpose of the jre package is
so that licensed independent software vendors (ISVs)
can bundle it with their Java application, if desired.
That way, the application and the Java version it has been
tested on can be installed together on customer machines, rather than
relying on whatever Java version is currently installed on those machines.
You must also install the "Modify System for Linux Applications" (MSLA) package on Open UNIX 8 which will tune your system to provide optimal performance of Linux applications. The latest information about, and version of, MSLA is available at http://www.caldera.com/products/openunix/lkp/applications.html. Select the following from the MSLA installation menu:$ pkginfo -l -c set lxcompat | grep STATUS STATUS: completely installed
Finally, you should install
the Open UNIX 8, Release 8.0.0 Maintenance Pack 3 package or later, e.g.
ou800pk3.image. This includes fixes to LKP which are necessary
for J2SE 1.3.1 for Caldera Linux to operate correctly. This
maintenance pack is available at
ftp:ftp.caldera.com/pub/openunix8/ou800pk.
/usr/java pathname,
installation actually places its contents into /opt/java-1.3.1/.
Then a symbolic link is made from /usr/java to
/opt/java-1.3.1/.
You can have multiple versions of Java installed on your system at
the same time. Installation of J2SE 1.3.1 will not automatically remove
any previous versions of Java from your system; it just changes the
/usr/java symbolic link.
You may still access other Java versions by directly naming their
actual installation point. For example, you can invoke Java 1.3.0
and verify its version
by the command /opt/java-1.3/bin/java -version.
Although multiple versions of the Java may be installed, the manual pages
for all releases are installed in /opt/man/man1/. This means that
installing
multiple versions will result in the pages being overwritten and therefore will
be the pages for the last version to be installed.
Documents such as the copyright, license, and other files are installed
into release specific directories under /usr/shared/doc/packages/.
The document files for J2SE 1.3.1 for Caldera Linux will be placed in
/usr/shared/doc/packages/java-1.3.1/ and will not conflict
with the document files of other packages.
jre package (jre-1.3.1-02a.rpm)
to be installed and
the jdk-debug package
(jdk-debug-1.3.1-02a.rpm)
requires the jdk package
(jdk-1.3.1-02a.rpm)
to be installed.
You must be root to install any J2SE 1.3.1 packages:
You can then install any additional packages:# rpm -i jre-1.3.1-02a.rpm
It is also important to note that, because of the manual page conflict mentioned above, if you install the# rpm -i jdk-1.3.1-02a.rpm # rpm -i jdk-debug-1.3.1-02a.rpm
jre-1.3.1-02a package,
and you have another version (e.g. jre-1.3) installed, the
installation will fail. At this point you can simply remove the
currently installed jre before applying the new package,
or you can force the installation by typing:
# rpm -i --replacefiles jre-1.3.1-02a.rpm
As previously mentioned, this will result in the jre-1.3.1 man pages
overwriting the pages that were in /opt/man/man1/. In addition,
note that
if you later choose to remove any version of the jre
package, these files will be completely removed. This applies to the
jdk package as well, which also includes manual pages.
For everything else, you may browse Sun's complete documentation for Java 2 SDK, Standard Edition Version 1.3.1 at http://java.sun.com/j2se/1.3/docs/index.html. This contains the very latest and most accurate documentation for J2SE 1.3.1 and J2SDK 1.3.1.
The Japanese version of the documentation may be found at http://java.sun.com/j2se/1.3/ja/docs/ja/index.html.
Both the English and Japanese versions of the documentation may be downloaded as a large HTML bundle at http://java.sun.com/j2se/1.3/docs.html.
Note that there are also useful
Sun and Caldera Linux demonstration uses of
J2SE 1.3.1 and J2SDK 1.3.1 at /usr/java/demo/ when
the jdk package has been installed.
J2SE 1.3.1 from OpenLinux is accessed at /usr/java/bin;
e.g. /usr/java/bin/java will bring up the Java
virtual machine.
After the Java packages are installed, we recommend that you
set PATH in your .profile startup file
(or whatever startup file is used by your shell)
to include the directory where the Java commands are installed,
/usr/java/bin.
If you are in Linux mode in Open UNIX 8 with LKP (e.g., you have executed
the linux command), then you can access J2SE 1.3.1 in the usual
way, e.g. /usr/java/bin/java will bring up the Java
virtual machine.
If you are in UNIX mode in Open UNIX 8 with LKP, then you will need to
prefix the command with the /linux filesystem, e.g.
/linux/usr/java/bin/java will bring up the Java
virtual machine.
However, at times the symbolic links across LKP are not set up so as to
allow this to work. In that case, "resolve" the /usr/java
symbolic link on the Linux side by yourself; e.g. do
/linux/opt/java-1.3.1/bin/java to bring up the Java
virtual machine.
When in UNIX mode,
to avoid confusion with the J2SE for Caldera UNIX that is installed
on the UNIX side at /usr/java/, you may want to use
full pathnames to access Java rather than put anything in your path.
In Linux mode,
modifying your startup file to include /usr/java/bin
may not be necessary, as LKP
usually creates a PATH with that in it,
when you execute the linux command.
After javac is used to compile source code that includes
a main method, use the chmod +x command to
set the execute permissions bit on for the .class
file that contains the main method.
Then you can execute a Java application simply by giving the name of the main class:
Linux will look for$ foo.class
foo.class by use of the
PATH environment variable, just as it would for
any other executable. foo.class must also be
in the CLASSPATH, as in normal execution.
Furthermore, by making a hard link or symbolic link such as
you will be able to execute the application simply by saying$ ln -s foo.class foo
This gives you the ability let users invoke utilities without knowing the utilities are written in Java. For this to work you must keep the name prefix intact and the class file intact. That is, you have to keep$ foo
foo.class
somewhere, and then you can make a hard or soft link
of foo to it. foo can be in another directory,
but you can't change
the name; i.e., you can't link bar to it. That's because once the
system invokes the JVM, it expects to find a foo.class file there.
For this same reason you also can't just rename foo.class to
foo, because the JVM will still need a foo.class.
(You could copy foo.class to foo,
but that will of course waste disk space compared to a link.)
Of course, you can always use the traditional way of executing a Java application:
In this case,$ java foo
java must be in the PATH,
and foo.class must be in the CLASSPATH.
The first-class executable feature works on both OpenLinux and
Open UNIX 8 with LKP. Note that a similar feature exists in
J2SE 1.3 for Caldera UNIX on the Open UNIX 8 native UNIX (non-LKP) platform;
in that product, javac sets the execute permission
for you, while here you have to do it yourself.
| Virtual Machine | Compiler | Threads | option to use |
|---|---|---|---|
| HotSpot | Client | native threads only | -client (this is the default if you specify nothing) |
| HotSpot | Server | native threads only | -server |
| Classic | none | native threads | -classic |
| Classic | none | green threads | -classic; also set THREADS_FLAG=green environment variable |
The virtual machine option, if used, must be the first one after the
java command.
Which virtual machine configuration to use?
HotSpot is a newer, faster, and generally better virtual machine technology than the older "classic VM" (which is what is used in the J2SE 1.3 for Caldera UNIX product).
Using the HotSpot client compiler generally gives good performance for short- and medium-lived applications, good start-up time for long-lived applications, and good extended performance for long-lived applications. Using the HotSpot server compiler generally gives maximum extended performance for longer-lived applications, at the cost of some extra start-up time. Experiment with both to see which is best for each of your applications.
Use HotSpot rather than the classic VM unless you have an existing application that for some reason is dependent upon the classic VM to execute properly, or unless your application has hit a HotSpot-related problem that no other solution has been found for. For example, if your application has uncovered a problem or limitation in the Linux threads library, using the classic VM with green threads will bypass the Linux threads library entirely. ("Green threads" implements Java threads entirely within one JVM user-space process, without relying upon operating system threads facilities, while "native threads" implements Java threads by using an operating system threads library.)
Note that if you do use the classic VM, performance will be slow: unlike with the J2SE 1.3 for Caldera UNIX product, no just-in-time (JIT) compiler is available for use with the classic VM on Linux. Thus all Java bytecode will be interpreted.
J2SE 1.3.1 for Caldera Linux augments this classpath with
an additional set of jar files found in /usr/share/java.
These are libraries installed there by other system packages
(such as, say, a web server or a parsing package).
The /usr/share/java libraries are added to the
end of the classpath. Thus, if you have a similar or equivalent
library that are you specifying (which for example can happen
with XML parsers), it will be seen first, and unpleasant
surprises will be avoided. However, you may still be surprised to
see classes appearing that you did not think were there at all.
Examples showing exactly how to build native code may be found
in /usr/java/demo/native when the jdk
package is installed.
On Open UNIX 8 with LKP, native code cannot be built with the Open UNIX 8 GCC compilers or with the Open UNIX Development Kit compilers. Such code would conform to the UnixWare ABI and would not interoperate correctly with the Linux Java implementation.
Similarly, if it is necessary for some reason for native code to make calls to Open UNIX 8 UNIX libraries (that do not have equivalents in OpenLinux), then J2SE for Caldera Linux cannot be used. Instead, you should use the J2SE 1.3 for Caldera UNIX implementation.
System.Properties
can be queried. Here are some of the values that will be returned
for J2SE 1.3.1 for Caldera Linux:
Realize that the operating system name will report as Linux regardless of whether you are running on "pure" OpenLinux, or OpenLinux through LKP in Linux mode, or OpenLinux through LKP in UNIX mode. That is because in all cases the Java implementation thinks it is running on a Linux machine.java.home=/opt/java-1.3.1/jre java.vendor=Caldera International, Inc. java.vendor.url=http://www.caldera.com/ java.vendor.url.bug=http://www.caldera.com/support/ java.version=1.3.1 java.vm.vendor=Caldera International, Inc. java.vm.version=Caldera-1.3.1_02a-FCS java.runtime.version=Caldera-1.3.1-02aFCS java.specification.version=1.3 java.class.version=47.0 java.compiler= os.arch=i386 os.name=Linux os.version=2.4.13
However, the operating system version may report differently in "pure" OpenLinux compared to OpenLinux through LKP, due to different versions of OpenLinux being installed (e.g., the version might be 2.4.0 instead of 2.4.13).
Caldera is committed to maintaining Java application compatibility across all platforms. Caldera does not superset or subset the Java 2 APIs as defined by Sun.
/linux/usr/java/bin/java may not work due to symbolic link
problems across LKP. If this happens, invoke Java by
/linux/opt/java-1.3.1/bin/java.
These are due to a missingFont specified in font.properties not found [-*-standard symbols l-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] Font specified in font.properties not found [-*-standard symbols l-medium-r-normal--*-%d-*-*-p-*-adobe-fontspecific] ...
symbol
font in the X server, which is running on
UNIX (not Linux) within Open UNIX 8 in the LKP scheme.
The solution is to add the additional fonts via the MSLA
package.
Note this problem can also happen when the
DISPLAY is remoted to another machine that does not have
this symbol font.
System.in, where the
standard input is coming from a pipe, may experience an incorrect
java.io.IOException: Illegal seek exception. This is due
to an LKP problem. A work-around is to create a
DataInputStream object from System.in
and do the reading from that object.
In addition, there is a separate and distinct Java 2 Standard Edition, v. 1.3.0_02, implementation from Caldera available for, and distributed with, the SCO OpenServer Release 5, UnixWare 7 Release 7.1.1, and Open UNIX 8 Release 8.0.0 operating systems. This is the product referred to here as J2SE 1.3.0 for Caldera UNIX. It is a "native" implementation that has been built on UnixWare 7 for execution on all three of those platforms.
J2SE 1.3.0 for Caldera UNIX is also a full implementation of the Sun Microsystems Java 2 Platform. The major internal difference between that Java implementation and this one is that the Caldera Linux implementation uses by default the Sun HotSpot virtual machine, while the Caldera UNIX implementation uses the Sun "classic VM" virtual machine together with a JIT compiler. For most applications, the HotSpot virtual machine will show better performance than the classic VM/JIT combination.
The J2SE 1.3.1 for Caldera Linux implementation cannot be used at all on the SCO OpenServer 5 or UnixWare 7 platforms; the J2SE 1.3 for Caldera UNIX implementation is the only Java implementation available for those platforms.
Copyright © 2002 Caldera International, Inc. All Rights Reserved.
Caldera, OpenLinux, SCO, SCO OpenServer, UnixWare, and Open UNIX are trademarks or registered trademarks of Caldera International, Inc. in the U.S.A. and other countries.
Sun, Sun Microsystems, Java, and HotSpot are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries, and are used under license.
UNIX is a trademark of The Open Group in the United States and other countries. Intel is a registered trademark of Intel Corporation. Netscape and Netscape Navigator are registered trademarks of Netscape Communications Corporation in the United States and other countries. Linux is a registered trademark of Linus Torvalds.
Caldera International, Inc. reserves the right to change or modify any of the product or service specifications or features described herein without notice. This document is for information only. No express or implied representations or warranties are made in this document.