RELEASE NOTES - Java(TM) 2, Standard Edition, v. 1.3.1_02a for Caldera(R) OpenLinux(R) and Open UNIX(R) 8 (with LKP) Operating Systems

Release Notes

JavaTM 2, Standard Edition, v. 1.3.1_02a
for Caldera® OpenLinux® and Open UNIX® 8 (with LKP) Operating Systems


CONTENTS

GENERAL INFORMATION

License

Please read the LICENSE file for the license terms of this Caldera® product.

Introduction

These are the release notes for the JavaTM 2 Standard Edition (J2SE), version 1.3.1_02a for the Caldera® OpenLinux® and Open UNIX® 8 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.

System Requirements and Supported Platforms

Software: Supported Caldera platforms:
  • Caldera OpenLinux Workstation 3.1 and 3.1.1

  • Caldera OpenLinux Server 3.1 and 3.1.1

  • Open UNIX 8 Release 8.0.0 operating system
    • requires Linux Kernel Personality (LKP) to be installed
    • requires the MSLA package to be installed
    • requires the Open UNIX 8, Release 8.0.0 Maintenance Pack 3 (or later) package to be installed

RAM: 64 MB
Disk Space: Minimum 80 MB

Changes in This Release

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:

PACKAGES

Package Name
Approx. Size
Contains
    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.

INSTALLATION

J2SE 1.3.1 for Caldera Linux packages are in rpm-style format. Accordingly, when installing these packages on Open UNIX 8, you must be in Linux mode. There are no pkgadd-style packages for this product.

Prerequisites

If you will be using J2SE 1.3.1 on Open UNIX 8, you must have all of the packages that are included in the "Linux Kernel Personality for Open UNIX 8" set installed. To determine if you have all of the required packages on your system, from UNIX mode check that the following is displayed:
$ pkginfo -l -c set lxcompat | grep STATUS
STATUS:  completely installed  
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:

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.

Installation Location and Multiple Java Versions

While the J2SE 1.3.1 for Caldera Linux is accessed through the /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.

Installation Instructions

The following package dependencies exist: all packages depend on and require the 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:

# rpm -i jre-1.3.1-02a.rpm
You can then install any additional packages:
# rpm -i jdk-1.3.1-02a.rpm
# rpm -i jdk-debug-1.3.1-02a.rpm
It is also important to note that, because of the manual page conflict mentioned above, if you install the 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.

DOCUMENTATION

The only documentation provided with J2SE 1.3.1 for Caldera Linux is man pages for the J2SE and J2SDK commands, and these Release Notes.

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.

USAGE NOTES

Using J2SE 1.3.1 from OpenLinux

In general, use of the J2SE 1.3.1 for Caldera Linux follows that which is described in the Sun documentation.

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.

Using J2SE 1.3.1 from Open UNIX 8 with LKP

In general, use of the J2SE 1.3.1 for Caldera Linux follows that which is described in the Sun documentation.

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.

Java Classes as First-Class Executables

Java on Linux provides a functional extension to the Sun Java 2 SE for use on Linux platforms: Java classes as first-class executables. This extension does not affect the Java 2 APIs; it just affects how Java can be invoked.

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:

$ foo.class
Linux will look for 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

$ ln -s foo.class foo
you will be able to execute the application simply by saying
$ 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.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:

$ java foo
In this case, 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.

The Virtual Machine Options

This product includes four different Java virtual machine possibilities:

Virtual MachineCompilerThreadsoption to use
HotSpotClientnative threads only-client (this is the default if you specify nothing)
HotSpotServernative threads only-server
Classicnonenative threads-classic
Classicnonegreen 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.

Additional CLASSPATH Libraries

Normally the classpath used by a Java virtual machine consists of the standard J2SE libraries together with any libraries or classes you specify.

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.

Native Code

If native method code or JNI Invocation native code is used in conjunction with J2SE 1.3.1 for Caldera Linux, it must be built with the GNU GCC compilers present in the OpenLinux distribution. That is because the native code must conform to the Linux application-binary interface (ABI) in order to interoperate correctly with this Linux ABI-built Java implementation.

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

If it is necessary for application code to determine characteristics of the platform it is running on, the Java class System.Properties can be queried. Here are some of the values that will be returned for J2SE 1.3.1 for Caldera Linux:
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
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.

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).

CONFORMANCE

This release of J2SE 1.3.1 for Caldera Linux has passed the Sun Java Compatibility Kit (JCK) 1.3a test suite, which is the most recent version of the JCK that is applicable to the Sun J2SE 1.3.1.

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.

KNOWN PROBLEMS

This section contains known problems or limitations that are specific to the Caldera implementation of J2SE 1.3.1 for Linux. For known problems with the Sun J2SE 1.3.1 reference implementation itself, see the Sun Developer ConnectionSM website ( http://developer.java.sun.com).

  1. When in Open UNIX 8 in UNIX mode, invoking Java by /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.

  2. When running graphical applications on Open UNIX 8 with LKP, you may see a flurry of warning messages like this:
    Font 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]
    ...
    
    These are due to a missing 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.

  3. On Open UNIX 8 with LKP, some programs that read from 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.

JAVA FOR CALDERA UNIX OPERATING SYSTEMS

These Release Notes describe the Java 2 Standard Edition, v. 1.3.1_02a implementation for the Caldera OpenLinux and Open UNIX 8 under LKP operating systems. This is an implementation built for Linux.

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.

ADDITIONAL INFORMATION LINKS

[TOP]


Last Updated: 2/19/2002

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.