Release Notes

Java^TM 2, Standard Edition, v. 1.4.2_14c
for
SCO^® UNIX^® Operating Systems

FCS - UnixWare 7.1.4
FCS - OpenServer 5.0.7
FCS - OpenServer 6.0.0

• GENERAL INFORMATION
  • License
    
  • Introduction
    
  • System Requirements and Supported Platforms
    
  • Changes in This Release
    
  • Distributed CA Certificates
    
• PACKAGES
  • The JRE Package
    
• INSTALLATION
• DOCUMENTATION
• DEVELOPER NOTES
  
  • Using Java 2 SDK for SCO UNIX
    
  • Java Classes as First-Class Executables
    
  • HotSpot Compilers: Client or Server
    
  • Threads: Native
    
  • Native Methods
    
  • Debugging Native Methods and the JVM
    
  • Additional Implementation Notes
    
  • Conformance
    
  • JDBC^TM
    
  • Fonts
• JAVA PLUG-IN
• KNOWN PROBLEMS
• JAVA FOR LINUX KERNEL PERSONALITY (LKP)
• ADDITIONAL INFORMATION LINKS

GENERAL INFORMATION

License

Introduction

Its status is FCS (First Customer Ship) for UnixWare 7.1.4, for OpenServer 5.0.7 MP3 or later releases, and for OpenServer 6.0.0.

This release of Java 2 Standard Edition contains:

• the Java 2 Runtime Environment, which allows SCO UNIX end users to run Java applets and applications on SCO UNIX operating systems
• the Java 2 Software Development Kit (J2SDK), which enables SCO UNIX OEMs, ISVs, and end users to develop Java applets and applications that conform to the Java 2 Core API
• the Java 2 Plug-in for Mozilla browsers released with UnixWare 7.1.4, OpenServer 5.0.7 and OpenServer 6.0.0.

This product is hereafter referred to as either "J2SE 1.4.2 for SCO UNIX" or "J2SDK 1.4.2 for SCO UNIX", depending upon which context the reference occurs in.

J2SE 1.4.2 for SCO UNIX is a full implementation of the Sun Microsystems^TM Java 2 Platform - the technology and environment described in the Sun^TM specifications of the Java 2 Platform, Standard Edition, v. 1.4.2_14c. (The _14c suffix indicates the patch level of the Sun J2SE that J2SE 1.4.2 for SCO UNIX corresponds to.)

This product was originally known as the Java 2 Standard Edition for SCO Operating Systems. In May 2001, the operating systems business of SCO, Inc., was acquired by and made part of Caldera International, Inc., and this product became known as the Java 2 Standard Edition for Caldera UNIX Operating Systems. In August 2002, Caldera International, Inc. announced that it would be changing its name to The SCO Group, Inc. (a change completed in May 2003), and this product is now known as the Java 2 Standard Edition for SCO UNIX Operating Systems.

System Requirements and Supported Platforms

J2SE 1.4.2 for SCO UNIX is not supported on older versions of the supported operating systems, such as SCO OpenServer Release 5.0.6 or UnixWare 7 Release 7.1.1, nor is it available for older operating systems, such as the SCO UnixWare 2 operating system.

J2SE 1.4.2 for SCO UNIX cannot be used with the older OSRcompat packages that were released together with older versions of UnixWare 7 and OpenServer.

For the most part the J2SE 1.4.2 is identical for all supported platforms, and everything in these release notes applies to all supported platforms unless otherwise noted.

[*] Package urwfonts is available as part of the UnixWare 7.1.3 and 7.1.4 and OpenServer 5.0.7 and 6.0.0 media kits and is automatically installed as part of Initial System Load if Java is installed. It is also available in the UnixWare and OpenServer Development Kit 7.1.3 or 7.1.4 and is downloadable from the J2SE 1.4.2 or J2SE 1.3.1 web download page under the specific OS at http://www.sco.com/support/download.html/. The urwfonts is part of the Java runtime JRE custom installable package available for OpenServer and will be installed with the Java runtime if needed.

[**] The required runtime on OpenServer 5.0.7 are the libraries contained in the package set OSRcompat version 8.0.2 provided along with this release in the SCO OpenServer Release 5.0.7 Maintenance Pack 3 as the "UDK Compatibility Libraries : UDKcompat - version 8.0.2Ac".

Changes in This Release

J2SE 1.4.2_14c

J2SE 1.4.2_14c for SCO UNIX is a re-release of the J2SE 1.4.2_14 for SCO UNIX containing a fix for numeric keypad data entry with the keyboard Num Lock active.

J2SE 1.4.2_14c supercedes all previous releases of J2SE 1.4.2.

J2SE 1.4.2_14b

J2SE 1.4.2_14b for SCO UNIX is a re-release of the J2SE 1.4.2_14 for SCO UNIX containing an urgent DST time zone fix from Sun.

• The introduction of the Olson TZ data, version 2005r or greater, may break backward compatibility for the Eastern, Hawaiian, and Mountain time zones, under certain circumstances. The Hawaiian TZ is only affected for historical data. Other American TZs such as PST and CST are not affected.

J2SE 1.4.2_14b supercedes the J2SE 1.4.2_14 release previously made available on the SCO Support web site.

J2SE 1.4.2_14

J2SE 1.4.2_14 for SCO UNIX is the latest and cumulative update to J2SE 1.4.2 and contains the latest fixes from Sun and the following SCO specific fix:

• A JVM abort when the mouse wheel is used on a scrolled List widget has been resolved. Proper scrolling of the List widget requires an updated [/udk]/usr/lib/libXm.so.1.3 scheduled for release in OSR 6.0.0 MP3, UW 7.1.4 MP4, and OSR 5.0.7 MP6.

J2SE 1.4.2_14 supercedes the J2SE 1.4.2_13 release previously made available on the SCO Support web site.

J2SE 1.4.2_13

J2SE 1.4.2_13 for SCO UNIX, previously available from the SCO Support download site, contained the then latest fixes from Sun including DST timezone changes and security issue resolutions for the following announced issue as well as some yet to be announced issues. In addition, the CA Root Certificates file (cacerts) is now populated with the root certificates that we have recieved permission to distribute; see section "Distributed CA Certificates" for details
J2SE 1.4.2_13 superceded the J2SE 1.4.2_12 release previously made available on the SCO Support web site.

• A problem with embedded Java JVM initialization within a thread application has been corrected.

Sun Alert ID

Description

102686

The JRE and Java Secure Socket Extension (JSSE) may verify incorrect RSA PKCS #1 v1.5 signatures if the RSA public key exponent is 3. This may allow applets or applications that are signed by forged signing certificates and websites with forged web server certificates to be verified as valid. For more information see: http://www.imc.org/ietf-openpgp/mail-archive/msg14307.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339

J2SE 1.4.2_12

J2SE 1.4.2_12 for SCO UNIX was the previous update to J2SE 1.4.2. It contains the latest fixes from Sun including timezone changes as well as bug fixes and enhancements for SCO Unix platforms. It supercedes the J2SE 1.4.2_11 release previously made available on the SCO Support web site.

• Java option -XX:+UseAltSigs was not honered in previous releases. The option functions as Sun intended in 1.4.2_12.

J2SE 1.4.2_11

J2SE 1.4.2_11 for SCO UNIX, an earlier SCO released update to J2SE 1.4.2, contained the latest fixes from Sun including corrections for a yet to be announced security issue as well as bug fixes and enhancements for SCO Unix platforms. It superceded the J2SE 1.4.2_10 release previously made available on the SCO Support web site and released with OpenServer 6.0.0 FCS or MP2.

• On OpenServer 5.0.7, the Java VM process (java_vm) started by the Mozilla browser to handle a Java applet would continue to run after the browser was terminated. The problem has been resolved.
• Fixes in java.nio.MappedByteBuffer support. Behavior difference and availability of APIs fsync(), fdatasync() and madvise() between Solaris and UnixWare (SVR5) resolved.

J2SE 1.4.2_10

J2SE 1.4.2_10 for SCO UNIX, the previous SCO released update to J2SE 1.4.2, contained the then latest fixes from Sun including corrections for the following security issues as well as bug fixes and enhancements for SCO Unix platforms. It superceded the J2SE 1.4.2_08 release previously made available on the SCO Support web site, released with OpenServer 5.0.7 MP4 or Openserver 6.0.0 FCS or MP1.

• The NetworkInterface.getNetworkInterfaces() method was not returning a complete list of network interfaces on an SVR5 system (UnixWare and OpenServer 6.0).
• The server option -XX:+AggressiveHeap would not take effect on SVR5 systems because the total physical memory was incorrectly calculated.
• The RandonAccessFile() contructor mode "d" (data synchronization) was incorrectly passed to the system open() function with a BSD O_DSYNC flag. While generally inocuous, it could result in an SVR5 kernel memory corruption when opening some devices and eventually result in a system panic.
• Availability of LARGEFILE support may not have been correctly detected in JVM runtime initialization.
• The jre/lib/font.properties file has been revised to use Lucida fonts provided with the J2SE release. The previous font.properties file has been renamed font.properties.BKUP.

Sun Alert ID	Description
102003	Three (3) security vulnerabilities with the use of "reflection" APIs in the Java Runtime Environment may (independently) allow an untrusted applet to elevate its priveleges. For example, an applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted applet.

J2SE 1.4.2_08

J2SE 1.4.2_08 for SCO UNIX, the previous SCO released update to J2SE 1.4.2, contained the then latest fixes from Sun including corrections for the following security issues. It superceded the J2SE 1.4.2_06 release previously made available on the SCO Support web site.

Sun Alert ID	Description
101749	A vulnerability in the Java Runtime Environment may allow an untrusted applet to elevate its priveleges. For example, an applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted applet.

J2SE 1.4.2_06

J2SE 1.4.2_06 for SCO UNIX was the previous SCO released update to J2SE 1.4.2. It superceded the J2SE 1.4.2_04 release previously made available on the SCO Support web site. It contains Java 1.4 2 plug-in support for SCO UNIX Mozilla browsers and the latest set of fixes from Sun including the following security fixes.

Sun Alert ID	Description
57591	A vulnerability in the Java Plug-in may allow an untrusted applet to escalate priveleges through JavaScript to Java communication.
57708	A vulnerability in the Java Plug-in may allow an untrusted applet to inappropriately interfere with another applet in the same web-page including causing it to incorrectly load non-code resources such as files and web pages.
57707	A vulnerability in the Java(TM) Runtime Environment with object deserialization may allow a remote attacker to cause the Java Virtual Machine to become unresponsive, resulting in a denial-of-service condition for the runtime environment and servers that run on the runtime environment.
57613	The XLST processor included with the Java(TM) Runtime Environment may allow an untrusted applet to read data from another applet that is processed using the XSLT processor and may allow the untrusted applet to escalate privileges.

It is available for download from the SCO web site at http://www.sco.com/support/download.html/.

J2SE 1.4.2_04

J2SE 1.4.2_04 for SCO UNIX, the previous release of J2SE 1.4.2, contains the then current set of security fixes and general fixes from Sun. The following Sun Java security alert were fixed in that release.

Sun Alert ID	Description
57555	Java Runtime Environment Remote Denial of Service (DoS) Vulnerability

J2SE 1.4.2 for SCO UNIX is a major new release compared to the previous J2SE 1.3.1 for SCO UNIX.

For a list of all the new Java features and enhancements from the J2SE 1.3 platform, see the Sun list at http://java.sun.com/j2se/1.4.2/docs/relnotes/features.html. Also see the Sun J2SE 1.4.2 Release Notes at http://java.sun.com/j2se/1.4.2/relnotes.html.

Potential compatibility problems between this J2SE 1.4.2 for SCO UNIX and the prior J2SE 1.3.1 for SCO UNIX are addressed by the Sun pages at http://java.sun.com/j2se/1.4.2/compatibility.html, http://java.sun.com/j2se/1.4.1/compatibility.html, and http://java.sun.com/j2se/1.4/compatibility.html.

The following changes specific to the J2SE 1.4.2 for SCO UNIX implementation have been made, relative to J2SE 1.3.1 for SCO UNIX:

• This is the first J2SE for SCO UNIX implementation to use the Sun HotSpot Java virtual machine; previous J2SE for SCO UNIX implementations used the Sun "classic" Java virtual machine together with a Sun "just-in-time" compiler enhanced by SCO. Compared to the classic VM, HotSpot has superior performance, scalability, and reliability. For more information on HotSpot see http://java.sun.com/products/hotspot/.
• There is now only one threads model, native threads. The previous user-space "green threads" model that existed in the classic VM, does not exist in HotSpot. The THREADS_FLAG environment variable is no longer used.
• The old-style, lower-level native methods from Sun JDK 1.0.2 (sometimes known as NMI) are no longer supported, since the HotSpot virtual machine does not implement them. The examples of them have been removed from the native methods demos. The standard JNI specification for native methods continues to be fully implemented.
• JNI code written in C++ should be compiled with the UDK C++ compiler. The limited support available in previous releases for using the GNU g++ compiler is even more limited now. This is because unlike the classic VM, the HotSpot VM is completely implemented in C++. Since it is built by the UDK C++ compiler, this makes co-existence between the UDK C++ and g++ runtime environments problematic.
• Profiling accuracy is greatly improved for the supporting platforms. The previous release's JVM_USE_RDTSC environment variable is no longer used.
• The packaging structure has been changed, such that the "pls" package no longer exists. The demos contained in that package have been moved to the "sdk" package, as have the SCO JDBC documentation and examples. The "_g" debugging versions contained in that package are no longer distributed.

Distributed CA Certificates

Prior to the J2SE 1.4.2_13 release, the system-wide keystore certificates file named "cacerts" in the release was empty. It was the responsibility of users to add the specific root CA certificates of interest to their Java installation.

Beginning with the release of J2SE 1.4.2_13, the "cacerts" file contains root CA certificates from several public Certificate Authorities. As permission to distribute other root CA certificates is obtained, they will added in subsequent updates. As before, users may add to or maintain their keystore with the Java keytool command. See the "keytool - Key and Certificate Management Tool" documentation for usage and the default password.

PACKAGES

The JRE Package

All J2SE 1.4.2 for SCO UNIX users must install the JRE package. It is the base package which other J2SE 1.4.2 for SCO UNIX packages depend upon.

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

The j2jre142 package is by default installed in /usr/java/, with that actually being a symbolic link to /opt/java2-1.4.2/.

However, it is possible for an ISV or system administrator to change where the JRE is installed.

ISVs wanting to do this would change the value of BASEDIR in the pkginfo file and then repackage the j2jre142 package with a different name. The JRE would then install into BASEDIR. System administrators wanting to do this would copy /var/sadm/install/admin/default somewhere else, modify the value of basedir there, and then tell pkgadd to use that alternate file with the -a option. Finally, if basedir=ask is set in that file, then the pkgadd command will prompt the installer for the desired package base directory.

Note that the other J2SE 1.4.2 packages require that the j2jre142 package be installed in /opt/java2-1.4.2.

INSTALLATION

SCO OpenServer Release 6.0.0

The j2se142 component for OpenServer 6.0.0 is an all inclusive J2SE 1.4.2 release including other Java packages. It contains the JRE, SDK, Java Plugin packages as well as the javaxcomm(java serial I/O support) and javasoap packages. If using the images on the SCO Product Download site, first download the following image:

• OSR6_Java2_142.VOLS.tar

mkdir JAVA142
cd JAVA142; tar -xf ../OSR6_Java2_142.VOLS.tar

scoadmin software
            or
custom

1. Pull down the "Software" menu and select "Install New".
2. When prompted for the host from which to install, choose the local machine and then "Continue".
3. In the "Select Media" menu, pull down the "Media Device" menu. Select "Media Images", then choose "Continue".
4. When prompted for the "Image Directory", enter the directory where you unwound the tar file of the package to be installed and choose "OK".
5. When prompted to select the software to install, the single software package in the directory will by highlighted. Choose "Install".

SCO OpenServer Release 5.0.7

The j2jre142 and j2sdk142 packages, version 1.4.2_03 (1.4.2Cc), and the prerequisite OSRcompat and urwfonts packages are available on the OpenServer 5.0.7 Supplement 3 CD. Subsequent patch releases of J2SE 1.4.2 are available from the OpenServer 5.0.7 specific section of the SCO Support Services web-page at http://www.sco.com/support/download.html/.

Software should be installed in the following order:

• Java 2 Runtime Environment
• Java 2 Software Development Kit
• Java 2 Plug-in

scoadmin software
            or
custom

1. Pull down the "Software" menu and select "Install New".
2. When prompted for the host from which to install, choose the local machine and then "Continue".
3. In the "Select Media" menu, select the appropriate CD-ROM drive; then choose "Continue".
4. When prompted to select the software to be installed, select and install, one component at a time, in the order specified above. Be careful to select the correct software version, i.e. 1.4.2. Click on "Install".
5. Repeat steps 1 through 4 for each remaining software component to be installed.

• OSR5_Java2_JRE_142.VOLS.tar
• OSR5_Java2_SDK_142.VOLS.tar
• OSR5_Java2_PLUGIN_142.VOLS.tar

mkdir JRE SDK PLUGIN

cd JRE; tar -xf ../OSR5_Java2_JRE_142.VOLS.tar
cd ../SDK; tar -xf ../OSR5_Java2_SDK_142.VOLS.tar
cd ../PLUGIN; tar -xf ../OSR5_Java2_PLUGIN_142.VOLS.tar

scoadmin software
            or
custom

1. Pull down the "Software" menu and select "Install New".
2. When prompted for the host from which to install, choose the local machine and then "Continue".
3. In the "Select Media" menu, pull down the "Media Device" menu. Select "Media Images", then choose "Continue".
4. When prompted for the "Image Directory", enter the directory where you unwound the tar file of the package to be installed and choose "OK".
5. When prompted to select the software to install, the single software package in the directory will by highlighted. Choose "Install".
6. Repeat steps 1 through 5 for each remaining software download file to be installed.

UnixWare 7 Release 7.1.4

If you choose not to install the J2SE 1.4.2 software at that time, you may install them later from the UW 7.1.4 Update CD 2 or the UW 7.1.4 UDK CD. Place either CD into the CD-ROM device and:

pkgadd -d cdrom1 j2jre142
pkgadd -d cdrom1 j2sdk142

Subsequent patch releases of J2SE 1.4.2 are available from the UnixWare 7.1.4 specific section of the SCO Support Services web-page at http://www.sco.com/support/download.html/. Follow the directions on the Getting Started Guide to install the JRE, SDK and Java Plug-ins as desired.

A copy of these or the current Release Notes will by installed in /opt/java2-1.4.2.

Installation of urwfonts package

Installation Location and Multiple Java Versions

While the J2SE is accessed through the /usr/java/ pathname, installation actually places its contents into /opt/java2-1.4.2/. Then a symbolic link is made from /usr/java/ to /opt/java2-1.4.2/.

For compatibility with older J2SE for SCO releases, a symbolic link is also made from /usr/java2 to /opt/java2-1.4.2/. Thus, for example, you may invoke the Java virtual machine with either the command /usr/java/bin/java or the command /usr/java2/bin/java.

You can have multiple versions of Java installed on your system at the same time. Installation of J2SE 1.4.2 will not automatically remove any previous versions of Java from your system.

If you already have, say, J2SE 1.3.1 for SCO on your system, all that the installation of J2SE 1.4.2 will do is change the /usr/java (and /usr/java2) symbolic link from /opt/java2-1.3.1 (the actual installation point of J2SE 1.3.1) to /opt/java2-1.4.2/. You may still access J2SE 1.3.1 directly by naming its actual installation point. For example, the command /opt/java2-1.3.1/bin/java will start up the J2SE 1.3.1 virtual machine.

However, if you happen to already have a JDK 1.1.8 or earlier 1.1.x for SCO version installed on your system, then you may not want the /usr/java symbolic link changed to point to J2SE 1.4.2 for SCO UNIX. For example, you may have applications that do not run correctly under Java 2, whose scripts are expecting Java 1.1.x to be in /usr/java. In this case, the install will notify you of the potential conflict, and give you a choice of whether you want /usr/java to be changed to point to J2SE 1.4.2 for SCO UNIX or whether you want it left alone. In the latter case, you would access J2SE 1.4.2 for SCO UNIX via /usr/java2 rather than /usr/java.

(The only exception to this is if you are installing J2SE 1.4.2 by default or upgrading your system from UnixWare 7 Release 7.1.1 or Open UNIX 8 Release 8.0.0 to UnixWare 7.1.4; the ISL or update is non-interactive and thus will always change the symbolic link. You can manually restore the symbolic link afterwards if you so desire.)

Being able to use /usr/java has several advantages: It is the place where Java is accessed on many other systems, and thus is often the place third-party scripts will look for Java. It is the place where Java first-class executable support on UnixWare 7 will look for Java. And it is the place that is by default added to your PATH environment variable when login accounts are created on UnixWare 7.

Note however that even if /usr/java is changed to point to J2SE 1.4.2 for SCO UNIX, the actual installation point of /opt/jdk-1.1.x of any JDK 1.1.x for SCO will be unchanged, and you can access its commands by using a full pathname. For example /opt/jdk-1.1.8/bin/java will start up the JDK 1.1.8 for SCO virtual machine.

Re-Installation of Other SCO Java Packages

This section applies only to UnixWare 7.1.4 and OpenServer 5.0.7.

In addition to the packages in J2SE 1.4.2 for SCO UNIX, SCO puts out other Java packages including javaxcomm (Java serial I/O support), javasoap (Java web services SOAP and XML support), and javajsse (Java SSL support). While not part of J2SE, these packages do install within /usr/java/ because they provide APIs within the javax extension namespace.

These packages will work together with J2SE 1.4.2 for SCO UNIX. However, if you already have one or more of them installed in conjunction with J2SE 1.3.1 for SCO UNIX, and then you install J2SE 1.4.2 for SCO UNIX (thereby switching the /usr/java/ symbolic link to /opt/java2-1.4.2/), you will have to re-install these other packages again. That is because their current actual location is within /opt/java2-1.3.1/, and thus they will not be seen within /opt/java2-1.4.2/.

Do not remove these other packages first; just pkgadd them a second time, and then they will be available for use with both J2SE 1.3.1 and J2SE 1.4.2 for SCO UNIX.

The OpenServer 6.0.0 J2SE 1.4.2 component (j2se142) contains both the javaxcomm and javasoap packages.

DOCUMENTATION

Instead, you may browse Sun's complete documentation for Java 2 SDK, Standard Edition Version 1.4.2 at http://java.sun.com/j2se/1.4.2/docs/index.html. This contains the very latest and most accurate documentation for J2SE 1.4.2.

The Japanese version of the documentation may be found at http://java.sun.com/j2se/1.4/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.4.2/download.html#docs.

Where the documentation differs depending upon the underlying operating system (such as with the SDK tool documentation), follow the "Solaris^TM" version (not the "Linux^TM" or "Win32" versions).

Note that there are also useful Sun and SCO UNIX demonstration uses of J2SE 1.4.2 and J2SDK 1.4.2 at /usr/java/demo/ when the j2sdk142 package has been installed.

DEVELOPER NOTES

Using Java 2 SE for SCO UNIX

After the Java 2 SE packages are installed, we recommend that you set PATH in your .profile startup file (or whatever startup file is used in your shell) to include the directory where the Java 2 commands are installed, /usr/java/bin .

However, on UnixWare 7 modifying your startup file may not be necessary, as login accounts are usually created with /usr/java/bin as part of the PATH.

Java Classes as First-Class Executables

HotSpot Compilers: Client or Server

A dynamic compiler compiler improves Java performance by, as the program is executing (hence the name), compiling Java method bytecode to native Intel^® IA-32 machine code. On subsequent executions of the method the machine code is executed instead of the bytecode being re-interpreted. Thus, a dynamic compiler is a run-time component, not a development component (as conventional language compilers are). Dynamic compilers are a transparent component: they are always there and always executing unless they are explicitly turned off by the user. Dynamic compilers are sometimes referred to as "just-in-time" (JIT) compilers (such as was used in prior classic VM-based J2SE for SCO UNIX implementations).

The HotSpot virtual machine in J2SE 1.4.2 for SCO UNIX has two dynamic compilers: the client compiler and the server compiler. They are selected by using -client or -server as the first option after the java command. The client compiler is the default.

The client compiler is generally intended for short- to medium-lived applications or for applications where quick start-up time is important; it does compiles quickly, but does not generate the most fully optimized code. The server compiler is generally intended for long-lived applications where start-up time is not an issue; it takes longer to do compiles, but generates the most optimized code.

As with any optimization choice, results will vary with individual applications, so measure both compilers on your application and see which is the more suitable to use.

You do not have read or use any of the information in the rest of this section in order to gain the benefit of the HotSpot dynamic compilers; the information is here only for those wanting a better understanding of what they do, or for those wanting to exercise further control over them, or for those trying to troubleshoot a problem within the VM.

The options described here apply to both the client and the server dynamic compilers:

• To see what methods are being compiled, use the java -XX:+PrintCompilation option.
• To compile all methods, use the java -Xcomp option.
• To compile no methods, meaning only interpret methods, use the java -Xint option.
• To compile only a particular method, use the java -XX:CompileOnly=name,name,... option, where the argument is a series of comma-separated package-name.class-name.method-name names.
• To adjust the priority of the internal VM thread that does compilation, use the java -XX:CompilerThreadPriority=n option, where n is an operating system priority significantly higher or lower than the default value of 96.

Threads: Native

The HotSpot virtual machine and thus J2SE 1.4.2 for SCO UNIX has only one threads model: "native threads".

"Native threads" refers to a scheme in which the Java virtual machine creates and manages Java threads using the operating system threads library - named libthread - and each Java thread is mapped to one threads library thread.

The user-space "green threads" model found in J2SE 1.3.1 and prior releases for SCO UNIX no longer exists.

Native Methods

The j2sdk142 package must be installed in order to compile native methods.

C and C++ native methods must be compiled and linked with the UnixWare and OpenServer Development Kit (UDK) or similar compiler from SCO.

This means that native methods for SCO OpenServer Release 5 cannot be built with the SCO OpenServer Release 5 Development System. Some of the reasons for this requirement include:

• native methods need the C/C++ 64-bit long long data type, to match the Java 64-bit long data type

• C++ native methods need for the C++ standard library to be a dynamic library (libC.so) rather than an archive (libC.a)

• native methods using the X Window System must reference X11R6 headers, since that is what the J2SE 1.4.2 for SCO UNIX AWT uses

• native methods must use the same calling conventions, header files, libraries, and other ABI aspects as the JVM, which has itself been built with the UDK.

On SCO OpenServer Release 6.0.0, using the OpenServer Release 6 Development System, native methods must be compiled by the C and C++ compilers in UDK/SVR5 mode, not in OSR mode, for the same reasons as above. UDK/SVR5 mode is the default when the compilers are invoked from /usr/ccs/bin/, or may be selected with the -Kudk option when the compilers are invoked from /osr5/usr/ccs/bin/.

SCO UNIX-specific examples of the commands needed to build old- and new-style native methods with C and C++ are included in the demos part of the J2SDK 1.4.2 for SCO UNIX distribution (when the j2sdk142 package is installed), in the directory /usr/java/demo/native,under the subdirectories

• jni_c_demo
• jni_c++_demo
• jni_invoc_demo.

Native methods using GCC

Another compiler system that can be used for building native methods is the GNU GCC compiler, described in general at http://gcc.gnu.org.

If JNI code is written in C, the GNU gcc compiler that generates code for the UDK ABI and environment may be used.

On UnixWare 7.1.3 and 7.1.4 this is the GNUgcc package within the open source OSTools product set that SCO builds and ships as part of the UDK CD-ROM. On SCO OpenServer Release 6.0.0, this is the GCC compiler that is made available from SCO.

On SCO OpenServer Release 5, the regular gcc for OpenServer cannot be used, since it generates code for the OpenServer ABI and environment. Instead, you must build the OpenServer-hosted, UDK-targeted gcc described at http://gcc.gnu.org/install/specific.html#ix86-*-udk. If you do not want to get engaged in building GCC, an alternative is to compile the JNI code on UnixWare 7 using the UnixWare 7 gcc compiler, and then move the resulting dynamic library over to SCO OpenServer. Note that after you do this, you will need to run /udk/usr/ccs/bin/elfmark -t udk on your library, so that the JVM and system loader realize it is a UDK-compliant binary.

The /usr/java/demo/native directories described above may also be used to run native methods examples with the GNU gcc compiler. Pass the option gcc into the mk scripts.

If JNI code is written in C++, the GNU g++ compiler is not recommended for use on any SCO UNIX operating system. This is because the HotSpot virtual machine is written in C++ and built with the UDK C++ compiler. Thus, it depends upon the UDK C++ runtime environment and standard library. JNI code built by GNU g++ in turn depends upon the g++ runtime environment and standard library. These two environments will often be incompatible within the context of the same process.

In particular, JNI Invocation will not work at all with the GNU g++ compiler.

For regular JNI code compiled by g++, it is known that the following C++ features cannot be used: exception handling, iostreams, set_new_handler, dynamic_cast.

If UnixWare 7 g++ is used to build JNI code that is then moved to SCO OpenServer Release 5, then the UnixWare 7 g++ standard library /usr/gnu/lib/libstdc++.so.2.10.0 must also be moved to OpenServer 5, to /udk/usr/gnu/lib/libstdc++.so.2.10.0. This is because the JNI code will likely depend on the standard library. Following the move, /udk/usr/ccs/bin/elfmark -t udk should be run on the standard library as well as the moved JNI code library.

Debugging Native Methods and the JVM

Debugging of Java applications is done with the J2SDK-provided jdb debugger, as described in the relevant Sun documentation.

Debugging of C or C++ native methods, however, must be done with the UDK debugger. This is also applicable to isolating or troubleshooting potential problems within the JVM itself, since the lower layers of the JVM are implemented in C and C++, not Java.

Core dumps should never occur within Java. If they do, then either there is an application bug in a native method, or there is an internal bug within the JVM, or there is an internal bug within an SCO UNIX operating system library.

If there is a core dump resulting from an application bug in a native method, the JVM will print the message "An unexpected exception has been detected in native code outside the VM." It will then attempt to specify the native code function name and library name that the core dump occurred in, as well as supply a Java-level traceback from that point. This might be enough information to guide you to the source of the problem, but if not, you'll have to look at the core dump.

Java process core dumps can become large; you may need to set ulimit -c unlimited to avoid having the core file be truncated (typically to 16 MB). If core files do get truncated, they will be unreadable by the UDK debugger.

Once read in by the UDK debugger, core dumps from the JVM will usually have a few levels of signal handlers on the stack subsequent to the actual point of failure. An example would be:

$ debug -ic -c core.17311 
Using /usr/java/bin/java as executable
Warning: No debugging information in /usr/java/bin/java
Core image of java (process p1) created
Created core image(s) of 8 thread(s) for process p1
CORE FILE [_kill]
SIGNALED 6 (abrt) in p1.1
        0xbff97ffc (_kill+12:)          jb     0xa4e 
debug> stack
Stack Trace for p1.1, Program java
*[0] _kill(0x439f, 0x6) [0xbff97ffc]
 [1] abort(presumed: 0xbfec8270, 0x804ef58, 0xbfde54ec) [0xbffd42fa]
 [2] std::abort(void)(0x4, 0x8046114, 0)        [0xbfa084ba]
 [3] os::abort(int)(presumed: 0x1, 0x804ef58, 0)        [0xbfde54e7]
 [4] os::handle_unexpected_exception(Thread *, int, unsigned char *, void *)(presumed: 0x80513d0, 0x8, 0xb3885f80)      [0xbfde3629]
 [5] JVM_handle_solaris_signal(0x8, 0x8046e98, 0x8046a88, 0x1)  [0xbfde8a4d]
 [6] signalHandler(0x8, 0x8046e98, 0x8046a88)   [0xbfde73c1]
 [7] _thr_sigacthandler(presumed: 0x8, 0x8046e98, 0x8046a88)    [0xbfef5616]
 [8] do_some_stl(int)(n=8)      [fib.C@45]
 [9] Java_nfib_fib(env=0x8051470, cls=0x8047140, n=5)   [fib.C@55]
 [10] ?()       [0xbbc47446]
debug> 

The actual point of failure is at frame level [8] in this case. (The core dump was produced by modifying the jni_c++_demo native methods demo to do an intentional divide-by-zero.)

Note also that you may not see the rest of the stack; it often ends as shown. And if you do see it, it is just be a bunch of internal implementation routines inside the JVM (with names like JavaCalls::call_virtual()) that won't tell you much. In other words, there is no debugging tool available that will show you both the Java stack and the native methods stack at the same time.

However, you can make use of the JVM's Java thread dumps for this purpose. These are what you see when a Java process aborts; you can also get one by doing ^\ (control-backslash) at the command line as a Java application is running (this is especially useful if a JVM process is hung, frozen, or looping) or equivalently by sending a SIGQUIT signal to the process, such as with the kill -3 command. (You can also get some of the same information by grabbing with or running under jdb.)

You'll see entries in the Java threads dump like

Full thread dump Java HotSpot(TM) Client VM (SCO-UNIX-J2SE-1.4.2_*FCS-UW7_BETA-OSR5*_20031215 mixed mode):
...
"Thread-4" prio=5 tid=0x0812ad00 nid=0xd runnable [b378c000..b378c9c8]
        at TL.foo(threadsloop.java:12)
        at TL.run(threadsloop.java:24)
...

When you use the UDK debugger to look at the Java process (either via a core dump or by grabbing a live process), use the debugger ps command to show the threads in the Java process. It will show both an "ID" for each thread, of the form p1.nn, and a "Thread" for each thread, which is an integer number that is the thread_t thread-id in the UnixWare 7 threads library.

The "nid" number in the Java threads dump corresponds to the "Thread" number in the UDK debugger threads dump. From this you can see the "ID" for that thread; that ID is the identification name used in various debugger commands.

So to continue our example from above, one line of the debugger ps output is:

debug> ps
Program    ID         Pid Thread State          Function   Location       Command
...
 java      p1.9     17613     13 Stopped        _poll      0xbffc3aec     /opt/java2-1.4.2/bin/java threadsloop 6 
...

debug> stack -p p1.9
Stack Trace for p1.9, Program java
*[0] _poll(0xb378e560, 0, 0x2710)       [0xbffc3aec]
 [1] _abi_select(0, 0xbfff8d4c, 0xbfff8d4c, 0xbfff8d4c, 0xb378e7d4)     [0xbffc5474]
 [2] os_sleep(long long, int)(presumed: 0x2710, 0, 0x1) [0xbfde71da]
 [3] os::sleep(Thread *, long long, int)(0x812a420, 0x2710, 0, 0x1)     [0xbfde85ce]
 [4] JVM_Sleep()        [0xbfd666aa]

Of course, to do real native methods debugging you'll want to run the JVM from within the debugger. To do this you'll need to invoke the JVM executable directly. (This is easier than it was in previous releases of J2SE for SCO UNIX, because as of J2SE 1.4.x there are no longer .java_wrapper scripts in front of the real executables.) The basic idea is:

$ debug -ic	# or can use graphical version
debug> create /usr/java/bin/java my_app ...
debug> run
debug>

If you do a lot of this kind of debugging it can be useful to set up an alias in your ~/.debugrc file, which allows you to define a whole series of convenience commands to set up a typical JVM debugging session. An example of a full .debugrc alias might be look something like:

alias c142 create -f none /opt/java2-1.4.2/bin/java $1 $2 $3 $4 $5 $6 $7 $8 ; 
	set %stack_bounds=no ; signal -i cld poll alrm usr1 ; set %thread_change=ignore ; set %wait=no 

The create -f none command tells the debugger to ignore child processes caused by forks done within the X Window System libraries. The stack_bounds setting avoids spurious warnings due to dynamically compiled code being executed. The signal -i command keeps the debugger from stopping on innocuous signals that the JVM handles.

Additional Implementation Notes

System Properties

java.home=/opt/java2-1.4.2/jre
java.vendor=The SCO Group, Inc.
java.vendor.url=http://www.sco.com/
java.vendor.url.bug=http://www.sco.com/support/
java.version=1.4.2

java.vm.vendor=Sun Microsystems Inc.
java.vm.version=SCO-UNIX-J2SE-1.4.2_*FCS-UW7_FCS-OSR5_FCS-OSR6*_20050419
java.class.version=48.0

while here are values that are specific to SCO OpenServer Release 5.0.7:

os.arch=IA32
os.name=OpenServer
os.version=5.0.7
java.vm.info=mixed mode

SCO OpenServer Release 6.0.0:

os.arch=IA32
os.name=OpenServer
os.version=6.0.0
java.vm.info=mixed mode

UnixWare 7.1.4:

os.arch=IA32
os.name=UnixWare
os.version=7.1.4
java.vm.info=mixed mode

Abstract Windowing Toolkit

Conformance

SCO is committed to maintaining Java application compatibility across all platforms. SCO does not superset or subset the Java 2 APIs as defined by Sun.

JDBC

Java Database Connectivity is a standard SQL database access interface for Java, providing uniform access for Java applications to a wide range of relational databases.

The J2SE API for applications accessing JDBC is the java.sql package, which is included in J2SE 1.4.2 for SCO UNIX. This conforms to the latest Sun JDBC 3.0 specification. This API requires an implementation, including a JDBC driver, in order to be used.

J2SDK 1.4.2 for SCO UNIX contains a SCO UNIX implementation of JDBC and includes a SCO UNIX JDBC driver. However, this implementation is out-of-date and relies upon a database interface product that is no longer supported. This implementation is only included and described in order to support SCO customers and ISVs who may already be using it. For all others, contact your database vendor or other ISV; they probably have a JDBC implementation for a given database that can be used with J2SE 1.4.2 for SCO UNIX.

This SCO UNIX JDBC implementation in J2SE 1.4.2 for SCO UNIX is compliant with the Sun JDBC 1.2 specification. It is not compliant with the later Sun JDBC 2.0 or current JDBC 3.0 specifications.

There is no need to separately install the SCO UNIX JDBC implementation, since it is part of the j2sdk142 installation. The SCO UNIX JDBC implementation is included in the /usr/java/jre/lib directory as sqlr.jar. To use it, include the appropriate path to this jar file in your CLASSPATH.

Documentation on how to use the SCO UNIX JDBC implementation is installed as part of the j2sdk142 package and may be read at file:/usr/java/scojdbc/doc/index.htm. Similarly, examples of how to use this implementation may be found at /usr/java/scojdbc/examples/.

This SCO UNIX JDBC implementation is built upon the former SCO, Inc. SQL-Retriever^TM product. It is necessary to separately install the SQL-Retriever product if you are interested in using it. The part of SCO that made SQL-Retriever is now known as Tarantella, Inc. As of April 2001, the SQL-Retriever product has been withdrawn from the market. However additional licenses for existing SQL-Retriever customers are available, new licenses for residual contractual requirements may still be available, and in any case if you already have it installed you can continue to use it. See http://www.tarantella.com/support/faq.html#sqlsupport for more information.

Fonts

Even for European languages, only a limited number of scalable fonts is available on SCO UNIX platforms. However, the SCO Open License Software Supplement has a collection of freely available X11 fonts in package freefonts which helps alleviate this problem.

If using the default /usr/java/jre/lib/font.properties, it is necessary that the Java logical font sansserif.0 or sansserif.plain.0 be specified and be installed as a font on the X server platform displaying the graphical user interface of the Java application. If using any of the other font properties files, it is necessary that Java logical fonts serif.0 or serif.plain.0 and serif.1 or serif.plain.1 are defined in the /usr/java/jre/lib/font.properties[.locale] file and that they be installed as a font on the X server platform displaying the graphical user interface of the Java application.

The consequences of missing fonts in Java 2 can be severe. For example, without package urwfonts the individual benchmark scores do not appear above their graph bars in the once-commonly used CaffeineMark benchmark GUI harness. As another example, the Java2D demo program gets spurious out of memory exceptions, security exceptions, and illegal argument exceptions, as well as not displaying its fonts properly. For these reasons installation of the urwfonts package is required for J2SE 1.4.2 for SCO UNIX.

When a Java program requests a particular font of a particular size, Java 2 looks for scalable fonts first. If nothing could match, then Java 2 will try to find the fonts whose sizes and types are as close as possible, including trying the fixed-size fonts if their size is close enough. This, sometimes, could cause the font displayed to look not as you wanted, if no appropriate fonts could be found on the system the Java program is running on.

You may find useful information on these and other font issues from Sun at http://java.sun.com/j2se/1.3/docs/guide/intl/addingfonts.html and at http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Font.html.

JAVA PLUG-IN

Java Plug-in is a mechanism whereby Java applets being executed in a browser may be run using the external Java virtual machine from the underlying operating system, rather than the internal Java virtual machine included with the browser.

This is important because the Mozilla browser does not have an internal Java virtual machine and installing the Java Plug-in allows such applets to run.

Additional general information about Java Plug-in may be found at http://java.sun.com/products/plugin/.

Note that Java Plug-in 1.4.2 can not be used with the Netscape Navigator 4.x or Communicator 4.x browsers that may be on SCO UNIX platforms; it may only be used with Mozilla browsers.

The Java Plug-in 1.4.2 for Mozilla browsers is installed by adding the package j2plg142, as described in the Installation section above. This will install Java Plug-in runtime directly in the J2SE runtime (JRE) and will install a link to the plug-in library in the plugins directory of the "offically" installed Mozilla browser. This will make the Java plug-ins available to all users on the system.

Note that these files do not include the Java virtual machine implementation itself; the one on the system already installed via package j2jre142 is used.

Installation of the Java plug-in 1.4.2 on your system will supercede any Java Plug-in 1.3.1 previously installed. Later reinstallation of the Java 1.3.1 plug-in will replace the Java 1.4.2 plug-in and such reinstallations should be avoided.

To verify that installation of Java Plug-in 1.4.2 is working correctly, you may run the simple Plug-in demo applet file:/usr/java/demo/plug-in/applet_id/applet_id.html (the j2sdk142 package, which contains all Java demos, must have been installed). This applet will display what Java virtual machine implementation and version it is running with.

A more complex Plug-in demo applet to test is found at file:/usr/java/demo/jfc/SwingSet2/SwingSet2.html. You may also run the applet demos found underneath /usr/java/demo/applets/.

In the Mozilla browsers, you can determine what plug-ins are installed by selecting "About Plug-ins" from the top-level "Help" menu.

The Java Plug-in Control Panel allows you to change the default settings used by Java Plug-in at startup. This tool is found at /usr/java/jre/bin/ControlPanel and its use is described in chapter 9 of the "Java Plug-in 1.4.2 Developer Guide" at http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/contents.html You may also invoke this tool from within the browser by using the URL file:/usr/java/jre/bin/ControlPanel.html. Unlike on some other systems, this URL is not added to the Mozilla browser bookmarks list automatically when Java Plug-in is installed; you may do this addition by hand if you wish.

Environment variables that modify the behavior of the Java virtual machine may still be used in the Java Plug-in context if desired.

Java Plug-in 1.4.2 may be removed from the system by doing a pkgrm j2plg142 command. The next time the browser is brought up, it will realize that the plug-in is no longer there.

KNOWN PROBLEMS

1. On some SCO UNIX platforms, the X11R6 implementation is currently built to only use TCP/IP as a connection mechanism. This means that even when working locally, you may need to issue an xhost +your_machine_name command.
2. There are some limitations regarding fonts for both European and for non-European languages (see Fonts section).
3. If you encounter an error such as "unsupported 4-bit depth" (color depth) when running Java graphical applications, the video configuration of your desktop may need to be reconfigured to a higher level, such as 1024x768 resolution with 256 colors.
4. The SCO UNIX JDBC driver is JDBC 1.2 compliant but not JDBC 2.0 or 3.0 compliant. Contact your database vendor for a more recent JDBC implementation.
5. Some multiple-level executable/library structures that use JNI Invocation will not work correctly, due to the semantics of dynamic libraries. In particular, an a.out that does a dlopen of a libuser.so that in turn invokes the Java virtual machine, will not work. An a.out that is linked with -luser but not -ljvm -lhpi that calls a libuser.so that in turn invokes the Java virtual machine, will also not work. Such an a.out must always be linked against -ljvm -lhpi itself. (See /usr/java/demo/jni_invoc_demo for the full set of system libraries to link against.)
6. On UnixWare 7 Release 7.1.3 prior to Update Pack 3, the file(1) command does not correctly recognize Java .class files. This is not problem with J2SE 1.4.2 per se, but with the underlying operating system.
7. Support for multicast routing is not available on SCO OpenServer Release 5. This is not problem with J2SE 1.4.2 per se, just that SCO OpenServer Release 5 doesn't support it.
8. On SCO OpenServer Release 5 only, after a comprehensive multicast Java application is run, the MulticastSocket.leaveGroup method may not relinquish the socket's membership in the group due to some unknown operating system or hardware related problem. Rebooting the machine will resolve this behavior.
9. On SCO OpenServer Release 5 only, giving the jdb "run" command does not result in the program under test starting to run. In this case, issue a "threads" command, and then a "run" command.
10. When using the KDE desktop, some graphical Java applications will appear with the top border of the window moved off the upper left corner of the screen. A work-around is to right-click along the bottom border of the window, and then do a "move" operation to pull the whole window into the visible part of the screen.
11. On SCO OpenServer Release 5 only, the locale setting that J2SE 1.4.2 for SCO UNIX needs may be different than the locale setting that OpenServer selects as part of system configuration. For example, setting the locale to the French language in the SCO desktop internationalization dialog will have the effect of setting the environment variable LANG=fr_FR.ISO8859-1. However, in order for J2SE 1.4.2 to change its default locale to the French one, it needs for LANG=fr_FR to be set; the fr_FR.ISO8859-1 value will not work. Thus, you should do something like:

    $ LANG=fr_FR /usr/java/bin/java my_app
    

    when invoking the JVM, to change the LANG value for the JVM (but not for any other OpenServer applications). (This is not a problem with J2SE 1.4.2 per se, but rather with the different locale setting conventions between UnixWare 7 and SCO OpenServer Release 5, and how those differences are reflected through the OSRcompat package set.)
12. The J2SE 1.4.2 for SCO UNIX implementation of the java.nio.channels.FileChannel.transferTo method has the high-performance characteristics suggested by the Sun J2SE documentation for the case where the target channel is a socket, but not for the case where the target channel is a file. This is because the implementation uses the UnixWare 7 sendv() API, which is supported for file-to-stream writes but not for file-to-file writes.
13. New with J2SE 1.4 is XML support as a core part of the J2SE specification. The XML parser included in J2SE 1.4.2 for SCO UNIX is the same as in Sun J2SE 1.4.x releases: the Sun "Project X" parser, also known as the Apache Crimson parser. While it supports both SAX and DOM parsing, it does not support W3C XML Schema way of constraining XML, but only the older Document Type Definition (DTD) language. If you try to validate an XML document referencing an XML Schema, you will get the diagnostic Warning: Valid documents must have a <!DOCTYPE declaration. followed by a bunch of errors.

    A better XML parser is available from the Java web services package javasoap that is contained within the SCOx Components available as part of UnixWare 7 Release 7.1.3 Update Packs 3 and 4 and UnixWare 7 Release 7.1.4. When that package is installed, the Apache Xerces-J Release 1.4.4 parser (see http://xml.apache.org/xerces-j/) will be installed.

    Apache Xerces-J is installed into the extensions classpath /usr/java/jre/lib/ext/xerces.jar, so you do not have to name it on a classpath yourself. Moreover, because the jar file has a service provider configuration file that registers itself for the javax.xml.parsers.DocumentBuilderFactory service, it effectively takes precedence over the J2SE 1.4.2 for SCO UNIX parser in the bootstrap classpath. Thus, once package javasoap is installed, Apache Xerces-J will become the XML parser that is used.

    Note that once the Apache Xerces-J Release 1.4.4 parser is installed there are several JCK tests that are known to fail. These tests pass if the newer Apache Xerces2 Java Parser Release 2.6.2 is installed instead. However the Xerces2 parser has not yet been integrated into the Java web services packages or the SCOx Components.

14. The Java packages in the SCOx Components CD released with UnixWare 7 Release 7.1.3 Update Pack 3 should not be used in conjunction with J2SE 1.4.2 for SCO UNIX. This is because that CD's javasoap package has a known problem with a missing class, and because that CD's javajsse package is obsolete and harmful. Instead, the SCOx Components should be used that are provided with UnixWare 7 Release 7.1.3 Update Pack 4 and UnixWare 7 Release 7.1.4.

JAVA FOR LINUX KERNEL PERSONALITY (LKP)

In addition, there is a separate and distinct Java 2 Standard Edition, v. 1.3.1, for Linux implementation available for the Linux Kernel Personality on UnixWare. It too is a full implementation of the Sun Microsystems Java 2 Platform.

On UnixWare 7 when the Linux Kernel Personality feature is installed, it is possible to run the Java implementation for Linux while in UNIX mode. To do this, access the J2SE 1.3.1 for Linux implementation through the /linux filesystem, as in this example:

$ /linux/opt/java-1.3.1/bin/java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build Caldera-1.3.1-02aFCS)
Java HotSpot(TM) Client VM (build Caldera-1.3.1_02a-FCS, mixed mode)

(You cannot currently use the more natural /linux/usr/java/bin/java because of a symbolic link not working across the filesystem divide. Of course, you can also use the linux command to go into Linux mode, after which you can access Java using /usr/java/bin/java.)

The J2SE 1.4.2 for SCO UNIX implementation described in these Release Notes may be still accessed as well, in the normal manner.

If native methods are used in conjunction with J2SE 1.3.1 for Linux, they must be built with the GNU GCC compilers present in the Linux distribution. They cannot be built with the UnixWare 7 GCC compilers or with the UDK compilers.

If a third-party J2SE 1.4.x for Linux implementation is installed on a UnixWare 7 system via LKP, similar considerations apply to the above. Note however that there are known problems with such third-party implementations on UnixWare 7 LKP; for example, java.nio functionality does not work.

The J2SE 1.3.1 for Linux implementation cannot be used on the SCO OpenServer 5 platform; the J2SE 1.4.2 for SCO UNIX implementation described in these Release Notes is the only Java implementation available for SCO OpenServer 5.

ADDITIONAL INFORMATION LINKS

• SCO and Caldera http://www.sco.com
• SCO Server Solutions http://www.sco.com/products/
• Java Technologies on SCO Systems http://www.sco.com/developers/java/
• SCO Product Documentation Library http://www.sco.com/support/docs/
• SCO FTP Download Site ftp://ftp.sco.com/pub/
• Tarantella http://www.tarantella.com

• The Java Language Specification, Second Edition
• The Java Virtual Machine Specification, Second Edition
• The Java Community Process^SM Program, which governs the evolution of Java

• Sun http://java.sun.com
• Java 2 SE Page http://java.sun.com/j2se/1.4
• Java 2 SE SDK version 1.4.2 New Features http://java.sun.com/j2se/1.4.2/docs/relnotes/features.html
• Java 2 Platform Compatibility with Previous Releases http://java.sun.com/j2se/1.4.2/compatibility.html
• Java 2 SE SDK version 1.4.2 Documentation
  • English http://java.sun.com/j2se/1.4.2/docs/index.html
  • Japanese http://java.sun.com/j2se/1.4/ja/docs/ja/index.html
• Java Plug-in Home Page http://java.sun.com/products/plugin/

The SCO Group, 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.