RELEASE NOTES - Java(TM) 2, Standard Edition, v. 1.4.2_14c for SCO(R) UNIX(R) Operating Systems (FCS - UnixWare 7.1.4 / FCS OpenServer 5.0.7 / FCS OpenServer 6.0.0)

Release Notes

JavaTM 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


CONTENTS

GENERAL INFORMATION

License

Please read the license.txt file for the license terms of this product.

Introduction

These are the release notes for the JavaTM 2 Platform, Standard Edition (J2SE), version 1.4.2_14c for SCO® UNIX® Operating Systems.

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:

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 MicrosystemsTM Java 2 Platform - the technology and environment described in the SunTM 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

Software:
Supported SCO UNIX platforms:
  • UnixWare® 7 Release 7.1.4 operating system
    • requires package urwfonts [*]

  • SCO OpenServerTM Release 6.0.0 operating system
    • requires package urwfonts [*]

  • SCO OpenServer Release 5.0.7 operating system
    • requires SCO OpenServer Release 5.0.7 Maintenance Pack 3
    • requires package urwfonts [*]
    • requires package set OSRcompat version 8.0.2 or higher[**]

RAM: 64 MB
Disk Space: Minimum 79 MB

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.

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:

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.

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.

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.

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.

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:

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

Package Name
Required Software
Approx. Size
Contains
    
    j2jre142
 urwfonts

 runtime
  (above)
  52 MB Runtime Support:
java, the Java virtual machine interpreter (JVM); the "client" and "server" dynamic compilers; Java Foundation Classes (JFC) & Swing Package; and basic API libraries: language support, I/O, AWT, networking, utilities, images, media, math, compression, and security.

Distributed applications and database access:
Remote Method Invocation (RMI); JavaBeansTM (component object model); JDBCTM (database access); Internationalization tools; Security tools; Java IDL tools.

    j2sdk142
 j2jre142   24 MB Development Tools:
appletviewer, the Java Applet Viewer; javac, the Java Compiler; jdb, the command-line Java debugger; javah, the C Header and Stub File Generator for native methods; javap, the Java Class File Disassembler; javadoc, the JAVA API Documentation Generator; jar, the Java Archive (JAR) tool; and assorted other commands used in Java development; class libraries used in Java development; header files used in native code development. Also Java demo applets and applications; demos of Swing functionality; native method demos; Java Plug-in demos.
    j2plg142
 j2jre142   2.3 MB Java 2 Plug-in for Mozilla browser, 1.2.1 through 1.7.x on UnixWare 7.1.4, OpenServer 5.0.7 and OpenServer 6.0.0.

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

Note that for each of these platforms, installation may be slightly different if you are installing J2SE 1.4.2 for SCO UNIX packages downloaded from SCO's web site at http://www.sco.com/support/download.html. In that case, follow the Getting Started instructions found as part of the download process.

SCO OpenServer Release 6.0.0

J2SE 1.4.2 for SCO UNIX is installed by default on SCO OpenServer Release 6.0.0. The J2SE 1.4.2_10 release is included in the OpenServer 6.0.0 MP2 updates and will be installed by default when OSR 6.0.0 MP2 is installed. J2SE 1.4.2_11 release should supercede that on the MP2 release. Ideally, MP2 should be installed before this update is installed.

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:

Make a subdirectory into which you can unwind the downloaded tar file.
mkdir JAVA142
cd JAVA142; tar -xf ../OSR6_Java2_142.VOLS.tar
Run the Software Manager with the command:
scoadmin software
            or
custom
or double-click on the Software Manager icon in the desktop.

  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

J2SE 1.4.2 for SCO OpenServer 5.0.7 is dependent on kernel changes that are part of the OSR 5.0.7 Maintenance Pack 3 release. MP 3 must be installed prior to installation of the Java JRE.

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:

If installing from the OpenServer 5.0.7 Supplement 3 CD, run the Software Manager with the command:
scoadmin software
            or
custom
or double-click on the Software Manager icon in the desktop.

  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.
If using the images on the SCO Product Download site, first download the following images: Make a subdirectory for each custom tar file that you downloaded.
mkdir JRE SDK PLUGIN
Unwind each tar file into the corresponding subdirectory.
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
Run the Software Manager with the command:
scoadmin software
            or
custom
or double-click on the Software Manager icon in the desktop.

  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

J2SE 1.4.2 for SCO UNIX is installed by default on UnixWare 7 Release 7.1.4 ISL or upgrade.

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

Typically, the urwfonts package would have been install during UW 7.1.3 Initial System Load (ISL). If you do not currently have urwfonts on your system, selecting installation of the J2SE 1.4.2 packages will cause urwfonts to be installed prior to installation of the j2jre142 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

This J2SE 1.4.2 for SCO UNIX release contains no bundled Java documentation beyond these Release Notes.

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 "SolarisTM" version (not the "LinuxTM" 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

In general, use of the Java 2 SE for SCO UNIX follows that which is described in the Sun documentation.

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

SCO has provided a functional extension to the Sun Java 2 SE for use on UnixWare 7 and OpenServer 6 platforms: Java classes as first-class executables. This extension does not affect the Java 2 APIs; it just affects how Java can be invoked.

When javac is used to compile one or more classes, it will set the execute permissions bit on for the .class file if the class contains a main method. (This happens on all SCO UNIX platforms.)

Then, on UnixWare 7 and OpenServer 6 you can execute a Java application simply by giving the name of the main class:

$ foo.class
These two UNIX releases (and later releases) 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.

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:

Threads: Native

Threads are an essential part of the Java language and API set, and every Java implementation must decide how to implement Java threads.

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

Only standard JNI-style native methods are supported in J2SE 1.4.2 for SCO UNIX. The old-style, lower-level native methods from Sun JDK 1.0.2 (sometimes known as NMI) are no longer supported.

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:

All of these items are satisfied by the UDK. The UDK can be used on SCO OpenServer Release 5 itself, or native method dynamic libraries can be built with the UDK on UnixWare 7 and then moved to SCO OpenServer Release 5.

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

Some of these subdirectories have further subdirectories. The first two directories give examples of Java calling C and Java calling C++. The last directory gives examples of the JNI Invocation API, meaning a C or C++ main program calling Java (and thus invoking the Java virtual machine underneath it). In all cases execute the mk script to run the example. It is highly recommended that you follow the command invocations given in all these examples, for unless the native code is built correctly, it will not work as intended.

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)
...
The "nid=0xd" contains the "native id" or thread number (decimal 13 in this case), and is your link between this dump and what the UDK debugger produces.

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 
...
which since "nid" 13 is "Thread" 13, tells us that Java thread "Thread-4" is the same as debugger thread "p1.9". Now we can use the debugger stack command on that thread:
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]
and voila we have both the Java stack and the native code stack for a given Java thread.

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

In general, one of the important characteristics of Java is that it behaves in exactly the same fashion on all platforms. However, there are a few areas where it may be useful to know how the J2SE has been implemented on SCO UNIX platforms. Some of these have already been discussed above; others are described here.

System Properties

If it is necessary for application code to determine which of the SCO UNIX platforms it is running on, the Java class System.Properties can be queried. Here are some of the values that will be returned by default on all SCO UNIX platforms:
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

This implementation uses the X Window System, version X11R6.1, and Motif® version 1.2, to implement the Java 2 Abstract Windowing Toolkit.

Conformance

This release of J2SE 1.4.2 for SCO UNIX has passed the Sun Java Compatibility Kit (JCK) 1.4a test suite, which is the most recent version of the JCK that is applicable to the Sun J2SE 1.4.2.

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-RetrieverTM 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

Java 2 looks for scalable fonts in TrueType, Type 1 or F3 formats. However, on SCO UNIX platforms fonts for most non-European languages, particularly those scalable fonts in TrueType, Type 1 or F3 formats, are not available. Consequently this release of J2SE 1.4.2 for SCO UNIX will have difficulty displaying the characters of those languages. For the time being, users of those foreign languages are advised to find the needed fonts (as applicable to SCO UNIX platforms) themselves, install them and add them to the appropriate /usr/java/jre/lib/font.properties[.locale] file of this release of J2SE 1.4.2 for SCO UNIX.

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

J2SE 1.4.2 for SCO UNIX platforms,starting with version 1.4.2_06, contains an implementation of Java Plug-in 1.4.2 for the Mozilla browser released with the UnixWare 7.1.4, OpenServer 5.0.7 and OpenServer 6.0.0 operating system products.

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

This section contains known problems or limitations with the SCO port of J2SE 1.4.2 to SCO UNIX platforms. For known problems with the Sun J2SE 1.4.2 reference implementation itself, see the Sun Developer ConnectionSM website ( http://developer.java.sun.com).

  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)

These Release Notes describe the Java 2 Standard Edition implementation for the SCO OpenServer 5 and UnixWare 7 operating systems. This is a "native" implementation that has been built on UnixWare 7 for execution on all of these platforms.

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

[TOP]


Last Updated: 2007-05-01

Copyright © 2006-2007 The SCO Group, Inc. All Rights Reserved.

SCO, SCO OpenServer, UnixWare, Open UNIX, Caldera are trademarks or registered trademarks of The SCO Group, Inc. in the U.S.A. and other countries.

SQL-Retriever, Tarantella, and Tarantella Enterprise 3 are trademarks or registered trademarks of Tarantella, Inc. in the U.S.A. and other countries.

Sun, Sun Microsystems, Java, Java Development Kit, JDK, JavaBeans, JDBC, and HotSpot are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries, and are used under license.

UNIX and Motif are registered trademarks of The Open Group in the United States and other countries. Intel is a registered trademark of Intel Corporation. Netscape, Netscape Navigator, and Netscape Communicator are registered trademarks of Netscape Communications Corporation in the United States and other countries. NonStop is a registered trademark of Compaq Computer Corporation. X Window System is a trademark of the Massachusetts Institute of Technology. Apache is a trademark of the Apache Software Foundation. IBM is a registered trademark of the International Business Machines Corporation in the United States and other countries. Linux is a registered trademark of Linus Torvalds.

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.