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

Release Notes

JavaTM 2, Standard Edition, v. 1.4.2_03
for SCO® UNIX® Operating Systems

FCS - UnixWare 7.1.4        Beta - OpenServer 5.0.7




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


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

Its status is FCS (First Customer Ship) for UnixWare 7.1.4 and UnixWare 7.1.3 Update Pack 4 and Beta for OpenServer 5.0.7 releases.

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_03. (The _03 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

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

  • UnixWare 7 Release 7.1.3 operating system
    • requires SCO Update license
    • requires UnixWare 7.1.3 Update Pack 4
    • requires package urwfonts [*]

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

RAM: 64 MB
Disk Space: Minimum 75 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 media kits and is automatically installed as part of Initial System Load if Java is installed. It is also available in the UnixWare 7.1.3 Update Pack 4 media or in the UnixWare and OpenServer Development Kit 7.1.3 or 7.1.4 and is downloadable from the J2SE 1.3.1 web download page

[**] 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 2 as the "UDK Compatibility Libraries : UDKcompat - version 8.0.2Ac".

Changes in This Release

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 Also see the Sun J2SE 1.4.2 Release Notes at

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,, and

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:


Package Name
Required Software
Approx. Size

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

 j2jre142   23 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.

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.


SCO OpenServer Release 5.0.7

The beta release of 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 2 release. MP 2 must be installed prior to installation of the Java JRE.

The j2jre142 and j2sdk142 packages, and the prerequisite OSRcompat and urwfonts packages are available on the OpenServer 5.0.7 Supplement 3 CD or from the "Java 2 Standard Edition, v 1.4.2_xx for SCO UNIX Operating Systems" on the SCO Products download site at

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 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
Unwind each tar file into the corresponding subdirectory.
cd JRE; tar -xf ../Java2_JRE_142.VOLS.tar
cd ../SDK; tar -xf ../Java2_SDK_142.VOLS.tar
Run the Software Manager with the command:
scoadmin software
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

UnixWare 7 Release 7.1.3 -- Update Service Pack 4

Install UnixWare 7.1.3 Update Service Pack 4

J2SE 1.4.2 is distributed as part of UnixWare 7.1.3 Update Service Pack 4. During installation of UP4, the systems administrator may optionally select (deselect) installation of the current J2SE 1.4.2 release. Installation of J2SE 1.4.2 will set the default Java VM on the system to be J2SE 1.4.2, i.e. the /usr/java symbolic link will be set to point to /opt/java2-1.4.2.

If you did not install J2SE 1.4.2 as part of the installation of UP4, you may rerun the uli command as directed in the Update Pack 4 New Features and Notes document provided with Update Pack 4; this time selecting the J2SE 1.4.2 packages desired.

A copy of these 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 Release 7.1.3 Update 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

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.


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 This contains the very latest and most accurate documentation for J2SE 1.4.2.

The Japanese version of the documentation may be found at

Both the English and Japanese versions of the documentation may be downloaded as a large HTML bundle at

Where the documentation differs depending upon the underlying operating system (such as with the SDK tool documentation), follow the "SolarisTM" version " 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.


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 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 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 on UnixWare 7 and SCO OpenServer Release ? - 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) from SCO.

This means that native methods 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.

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 last directory gives examples for C and C++ of the JNI Invocation API. 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

If JNI code is written in C, the GNU gcc compiler that generates code for the UDK 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 5, the regular gcc for OpenServer cannot be used; instead, you must build the OpenServer-hosted, UDK-targeted gcc described at*-udk.

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 cannot be used. 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. JNI code built by GNU g++ in turn depends upon the g++ runtime environment. These two environments are incompatible within the context of HotSpot and cannot exist within the same process.

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]

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

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

java.vm.vendor=Sun Microsystems Inc.

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

os.version=5.0.7 mode

UnixWare 7.1.4:

os.version=7.1.4 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.


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.


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 /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 for more information.


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/[.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/, 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/[.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 and at


This release does not yet provide a Java Plug-in.


This section contains known problems or limitations with the SCO port of J2SE 1.4.12to SCO UNIX platforms. For known problems with the Sun J2SE 1.4.2 reference implementation itself, see the Sun Developer ConnectionSM website (

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

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



Last Updated: 2004-04-22

Copyright © 2004 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.

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.