Release Notes

Java^TM 2, Standard Edition 5.0, update 09
for
SCO^® UNIX^® Operating Systems

FCS - UnixWare 7.1.4
FCS - OpenServer 6.0.0

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

GENERAL INFORMATION

License

Introduction

Its status is FCS (First Customer Ship) for UnixWare 7.1.4 and for OpenServer 6.0.0.

This release of Java 2 Standard Edition contains:

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

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

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

Previous versions of this product were 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 those versions of the product and this product are now known as the Java 2 Standard Edition for SCO UNIX Operating Systems.

System Requirements and Supported Platforms

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

The J2SE 5.0 is identical for all supported platforms, and everything in these release notes applies to all supported platforms.

Changes in This Release

J2SE 5.0, update 09

J2SE 5.0, update 09 for SCO UNIX is a significant update to the J2SE 5.0 product. It encompasses Sun's updates 07, 08 and 09 and contains the following fixes or enhancements:

• Daylight Savings Time timezone changes that go into effect in 2007.
• Additional Root CA certificates have been added to the cacerts file; see section "Distributed CA Certificates" for details.
• A problem with embedded Java JVM initialization within a threaded application has been corrected.
• Several security issues have been resolved including the publicly announced issues listed below. In addition, security issues resolved in Sun's preliminary J2SE 5.0, update 10 release currently in development have been incorporated in this SCO product release.

The J2SE 5.0, update 09 release supercedes the J2SE 5.0, update 06 previously released on the SCO Support web site.

Sun Alert ID	Description
102662	A security vulnerability in the JRE Swing library may allow an untrusted applet to access data in other applets.
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 5.0, update 06

J2SE 5.0, update 06, was the initial J2SE 5.0 product release on SCO UNIX platforms. See the list of supported platforms above.

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

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

Potential compatibility problems between this J2SE 5.0 for SCO UNIX and the prior J2SE 1.4.2 for SCO UNIX are addressed by the Sun pages at http://java.sun.com/javase/technologies/compatibility.jsp. Potential compatibility problems between the previous 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.

The following changes specific to the J2SE 1.4.2 for SCO UNIX implementation relative to J2SE 1.3.1 for SCO UNIX apply to the J2SE 5.0 for SCO UNIX:

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

Distributed CA Certificates

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

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

PACKAGES

The JRE Package

All J2SE 5.0 for SCO UNIX users must install the JRE package. It is the base package which other J2SE 5.0 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 j2jre150 package is by default installed in /usr/java/, with that actually being a symbolic link to /opt/java2-1.5.0/.

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 j2jre150 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 5.0 packages require that the j2jre150 package be installed in /opt/java2-1.5.0.

MULTIPLE JAVA 2 SE RELEASES

J2SE 1.3.1 ==> /opt/java2-1.3.1
J2SE 1.4.2 ==> /opt/java2-1.4.2
J2SE 5.0    ==> /opt/java2-1.5.0

The installation of the JRE piece for each of these major point releases will automatically symbolicly link /usr/java and /usr/java2 to point to the "newly" installed JRE directory. System administrators can and should readjust these symbolic links as needed by their specific system and software requirements.

Other software released by SCO for your SCO UNIX platform as well as third party applications that use Java, may require a specifc J2SE major version. That software may either reference the J2SE of interest through:

• an environement variable such as JAVA_HOME that points to /usr/java or directly to the installation directory /opt/java2-1.x.x.
• an absolute command path, either /usr/java/bin/command or /opt/java2-1.x.x/bin/command.

Caution: Before removing earlier/other major versions of J2SE on your system, be certain that other installed software does not require that version. For example, the Apache-Tomcat product released on UnixWare 7.1.4 and OpenServer 6.0.0 have been configured, tested and certified with J2SE 1.4.2. Removal of that JRE will result in Tomcat failing to start.

INSTALLATION

SCO OpenServer Release 6.0.0

If using the images on the SCO Product Download site, first download the following image:

• OSR6_Java2_150.VOLS.tar

mkdir JAVA150
cd JAVA150; tar -xf ../OSR6_Java2_150.VOLS.tar

scoadmin software
            or
custom

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

UnixWare 7 Release 7.1.4

If using the images on the SCO Product Download site, first download the following imags:

• j2jre150.ds.Z
• j2sdk150.ds
• j2plg150.ds

zcat   j2jre150.ds.Z   |   pkgadd -d - all

pkgadd   -d  `pwd`/j2sdk150.ds
pkgadd   -d  `pwd`/j2plg150.ds

pkgadd   -d  `pwd`/j2jre150.ds
pkgadd   -d  `pwd`/j2sdk150.ds
pkgadd   -d  `pwd`/j2plg150.ds

Future Updates to Java 2 SE 5.0

Subsequent patch releases of J2SE 5.0 are available from the SCO UNIX 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 Plugin as desired.

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

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.5.0/. Then a symbolic link is made from /usr/java/ to /opt/java2-1.5.0/.

For compatibility with older J2SE for SCO releases, a symbolic link is also made from /usr/java2 to /opt/java2-1.5.0/. 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.5.0 will not automatically remove any previous versions of Java from your system.

If you already have, say, J2SE 1.4.2 for SCO on your system, all that the installation of J2SE 1.5.0 will do is change the /usr/java (and /usr/java2) symbolic link from /opt/java2-1.4.2 (the actual installation point of J2SE 1.4.2) to /opt/java2-1.5.0/. You may still access J2SE 1.4.2 directly by naming its actual installation point. For example, the command /opt/java2-1.4.2/bin/java will start up the J2SE 1.4.2 virtual machine. Other applications such as Apache/Tomcat invoke the version of Java either by the absolute installation path or through a setting of an environment variable.

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.

Re-Installation of Other SCO Java Packages

This section applies only to UnixWare 7.1.4.

In addition to the packages in J2SE 5.0 for SCO UNIX, SCO puts out other Java packages including javaxcomm (Java serial I/O support) and javasoap (Java web services SOAP and XML 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 5.0 for SCO UNIX. However, if you already have one or more of them installed in conjunction with J2SE 1.4.2 for SCO UNIX, and then you install J2SE 5.0 for SCO UNIX (thereby switching the /usr/java/ symbolic link to /opt/java2-1.5.0/), you will have to re-install these other packages again. That is because their current actual location is within /opt/java2-1.4.2/, and thus they will not be seen within /opt/java2-1.5.0/.

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.4.2 and J2SE 5.0 for SCO UNIX.

The OpenServer 6.0.0 J2SE 5.0 component (j2se150) contains both the javaxcomm and javasoap packages.

DOCUMENTATION

Instead, you may browse Sun's complete JDK^TM 5.0 Documentation at http://java.sun.com/j2se/1.5.0/docs/index.html. This contains the very latest and most accurate documentation for J2SE 5.0.

The Japanese version of the documentation may be found at http://java.sun.com/j2se/1.5.0/ja/docs/ja/index.html.

Both the English and Japanese versions of the documentation may be downloaded at http://java.sun.com/javase/downloads/index.jsp#docs.

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

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

DEVELOPER NOTES

Using Java 2 SE for SCO UNIX

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

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

Java Classes as First-Class Executables

HotSpot Compilers: Client or Server

A dynamic compiler 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 5.0 for SCO UNIX, as in J2SE 1.4.2, has two dynamic compilers: the client compiler and the server compiler. They are selected by using -client or -server as the first option after the java command. The client compiler is the default.

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

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

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

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

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

Threads: Native

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

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

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

Native Methods

The j2sdk150 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) on UnixWare 7.1.4 or with the OpenServer 6.0.0 Development System using the SVR5 ABI on OpenServer 6.0.0.

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

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

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

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

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

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

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

• jni_c_demo
• jni_c++_demo
• jni_invoc_demo.

Native methods using GCC

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

If JNI code is written in C, a 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 built and shipped as part of the UDK CD-ROM. On SCO OpenServer Release 6.0.0, there is no GCC compiler that is made available from SCO.

The gcc compiler from SCO OpenServer Release 5 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.

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.5.0_06_*BETA-UW714-OSR6*_20060706, mixed mode):
...
"Thread-4" prio=5 tid=0x0812ad00 nid=0xd runnable [b378c000..b378c9c8]
        at TL.foo(threadsloop.java:12)
        at TL.run(threadsloop.java:24)
...

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

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

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

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

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

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

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

If you do a lot of this kind of debugging it can be useful to set up an alias in your $HOME/.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.5.0/bin/java $1 $2 $3 $4 $5 $6 $7 $8 ; 
	set %stack_bounds=no ; signal -i cld poll alrm usr1 ;
	set %thread_change=ignore ; set %wait=no 

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

Additional Implementation Notes

System Properties

java.home=/opt/java2-1.5.0/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.5.0

java.vm.vendor=Sun Microsystems Inc.
java.vm.version=SCO-UNIX-J2SE-1.5.0_*FCS-UW7-OSR6*_yyyymmdd
java.class.version=49.0

while here are values that are specific to 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

Signals

• not attempt to make any use of SIGUSR1 or SIGUSR2
• the java process should be started with the option -XX:+UseAltSigs

This implementation interprets SIGQUIT as a request for a Java threads dump. JNI code should not attempt to use SIGQUIT.

In some contexts this implementation intentionally raises SIGSEGV signals in order to implement null reference checking and stack overflow checking. JNI code that accidentally or intentionally raises SIGSEGV will function properly (the JVM will handle the signal, issue a Java threads dump, and shut down). However you should not send a random SIGSEGV signal to a Java process (as is sometimes done in QA testing) because if the JVM is in one of the contexts where SIGSEGV is intentionally used, it will get confused and undefined behavior will result.

Finally, this implementation will handle any "fatal error" signals such as SIGBUS, SIGILL, etc., and proceed to issue a Java threads dump and shut down the JVM. This processing will function properly even if the signal is sent randomly to the Java process.

Conformance

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

JDBC

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

The J2SE API for applications accessing JDBC is the java.sql package, which is included in J2SE 5.0 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. Contact your database vendor or other ISV; they probably have a JDBC implementation for a given database that can be used with J2SE 5.0 for SCO UNIX.

Fonts

1. the jre/lib/fonts installation directory. On OpenServer this would be in the custom component SSO directory tree, not the user visible location in
2. installed in a way supported by the OS (using the pkgadd command on UnixWare, registering with the X font server on OpenServer 6.0.0)

For complete details on font configuration, usage and issues see the relevant Sun documentation:

1. "Supported Fonts" at http://java.sun.com/j2se/1.5.0/docs/guide/intl/font.html
2. "Font Configuration Files" at http://java.sun.com/j2se/1.5.0/docs/guide/intl/fontconfig.html

JAVA PLUG-IN

Java Plugin 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 Plugin allows such applets to run.

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

Note that Java Plugin 5.0 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 Plugin 5.0 for Mozilla browsers is installed by adding the package j2plg142, as described in the Installation section above. The Java Plugin is automatically installed, unless deselected, when installing the j2se150 OpenServer 6.0.0 component. This will install Java Plugin runtime directly in the J2SE runtime (JRE) and will install a link to the plugin library in the plugins directory of the "offically" installed Mozilla of Firefox browser. This will make the Java Plugin 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 Plugin 5.0 on your system will supercede any Java Plugin previously installed. Later reinstallation of earlier versions of Java Plugin will replace the Java 5.0 Plugin and such reinstallations should be avoided.

To verify that installation of Java Plugin 5.0 is working correctly, you may run the simple Plugin demo applet file:/usr/java/demo/plugin/applet_id/applet_id.html (the j2sdk150 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 plugin 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/plugin/.

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

The Java Plugin Control Panel allows you to change the default settings used by Java Plugin at startup. This tool is found at /usr/java/jre/bin/ControlPanel and its use is described in chapter 9 of the "Java Plugin Guide" at http://java.sun.com/j2se/1.5.0/docs/guide/plugin/developer_guide/contents.html

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

Java Plugin 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 plugin is no longer there.

KNOWN PROBLEMS

1. On some SCO UNIX platforms, the X11R6 implementation is currently built to only use TCP/IP as a connection mechanism. This means that even when working locally, you may need to issue an xhost +your_machine_name command.
2. Font configuration has changed from earlier J2SE versions. (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 at least 256 colors.
4. 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.)
5. 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.
6. The J2SE 5.0 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.
7. 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 5.0 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.

ADDITIONAL INFORMATION LINKS

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

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

• Sun http://java.sun.com
• Java 2 SE 5.0 Page http://java.sun.com/j2se/1.5.0
• Java 2 SE SDK version 1.5.0 New Features http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html
• Java 2 Platform Compatibility with Previous Releases http://java.sun.com/javase/technologies/compatibility.jsp and http://java.sun.com/j2se/1.4.2/compatibility.html
• Java 2 SE SDK version 1.4.2 Documentation
  • English http://java.sun.com/j2se/1.5.0/docs/index.html
  • Japanese http://java.sun.com/j2se/1.5.0/ja/docs/ja/index.html
• Java Plugin Home Page http://java.sun.com/products/plugin/

The SCO Group, Inc. reserves the right to change or modify any of the product or service specifications or features described herein without notice. This document is for information only. No express or implied representations or warranties are made in this document.