Contents

License

Introduction

This product is a full implementation of Sun Microsystems' Java Development Kit 1.1.3. It enables SCO OEMs, ISVs, and end users to develop and run applets and applications that conform to the Java 1.1 Core API.

Note that in fact this release incorporates SunSoft's JDK 1.1.3A and 1.1.3D fixes and enhancements to JavaSoft's JDK 1.1.3; this is done to support the Java Workshop, Java Studio, and JIT compiler products found in the UnixWare/OpenServer Development Kit (UDK).

This JDK product is being released on all three SCO operating system platforms: UnixWare 7, OpenServer (5.0.4), and UnixWare 2 (2.1.2).

(The JDK should also work on OpenServer 5.0.0 and 5.0.2, but is not conformance tested on those platforms.)

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

The SCO JDK-1.1.3 is packaged in two separate packages:

• jdk113: available both on the UnixWare 7 Base OS CD (part of BaseWeb) set and the UDK CD.
• jdk113pls: available on the UDK CD.

The jdk113 includes the essential runtime engine of Java, that is, the equivalent of an OS's kernel and libraries:

• Java Virtual Machine, JVM (the java command)
• appletviewer, the Java Applet Viewer
• basic API libraries
  • language support
  • I/O
  • AWT
  • networking
  • utilities
  • images, media
  • math
  • compression
  • security

The jdk113 also includes Java development tools:

• 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

The jdk113 also includes additional components to support distributed applications and database access:

• Remote Method Invocation (RMI)
• Java Beans (component object model)
• JDBC (database access)

The jdk113pls includes

• The JavaSoft documentation which contains a full description of the different parts of the JDK
• Many interesting Java demo applets and applications including some native method demos
• Debug versions of many commands, utilities and libraries

Installation

OpenServer 5.0.4

If the UDK Compatibility Module for OpenServer (package name OSRcompat) is not already installed on our system, you need to mount the UDK CD-ROM and install the package OSRcompat:

# mount -r /dev/cd0 /mnt
# pkgadd -d /mnt  OSRcompat

When that installation is complete, install the core JDK-1.1.3 (package name jdk113):

# pkgadd -d /mnt  jdk113

Then you can install the JDK-1.1.3 Plus (package name jdk113pls):

# pkgadd -d /mnt  jdk113pls

UnixWare 2.1.2

If the UDK Compatibility Module for UnixWare (package name UW2compat) is not already installed on our system, you need to mount the UDK CD-ROM and install the package UW2compat:

# mount -F cdfs -r /dev/cdrom/* /mnt
# pkgadd -d /mnt  UW2compat

If your machine has more than one CD-ROM drive, specify the CD-ROM device exactly (e.g. /dev/cdrom/c0b0t6l0).

When that installation is complete, install the core JDK-113 (package name jdk113):

# pkgadd -d /mnt  jdk113

Then you can install the JDK-113 Plus (package name jdk113pls):

# pkgadd -d /mnt  jdk113pls

Alternatively, the graphical desktop tool App_Installer may be used to install these packages.

Note that you may need to increase certain system memory limits; see Using JDK 1.1 for SCO below.

UnixWare 7

However, if you de-selected the jdk113 during ISL, you can install it from UnixWare 7 CD in the following way:

Mount the CD-ROM and install the JDK (package name jdk113):

# mount -F cdfs -r /dev/cdrom/* /mnt
# pkgadd -d /mnt  jdk113

Documentation

Document	File/Link Name
these release notes	ReleaseNotes.html
JavaSoft documentation for JDK 1.1.3 (same as for 1.1.4)	docs/index.html
JavaSoft demos for JDK 1.1.3	demo/
documentation on SCO's JDBC implementation and SCO's SQL-Retriever product	see JDBC section

Note that these documents are not integrated into the graphical help system on your platform (e.g. the ScoHelp).

Also note that much of this documentation is from JavaSoft, but should be read in an SCO context. For instance, for "Solaris" read any of the three SCO platforms (UnixWare 7, OpenServer 5.0.4, UnixWare 2.1.2). For customer support, any of the normal SCO support mechanisms should be used, rather than contacting Sun.

Using JDK 1.1.3 for SCO

After the JDK packages are installed, you probably want to set PATH in your .profile to include the directory where the JDK commands are installed, /usr/java/bin. On UnixWare 7 systems, this will usually have been done for you already when your account was created.

On UnixWare 2.1.2, applications of significant size are likely to get "out of memory" errors with the default memory limits provided by the operating system. To fix this, do the following as root:

# /etc/conf/bin/idtune -m HVMMLIM 0x7FFFFFFF
# /etc/conf/bin/idtune -m HDATLIM 0x7FFFFFFF
# /etc/conf/bin/idtune -m SVMMLIM 0x7FFFFFFF
# /etc/conf/bin/idtune -m SDATLIM 0x7FFFFFFF
# /etc/conf/bin/idbuild

On all three platforms, you need to give an xhost command for your machine if you are using appletviewer (see Known Problems below).

Extensions to Sun JDK 1.1.3

Java Classes as First-Class Executables

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

$ foo.class

Furthermore, by making a hard link or symbolic link such as

$ ln -s foo.class foo

$ foo

Of course, you can always use the traditional way of executing a Java application:

$ java foo

Native Methods

C and C++ native methods must be compiled and linked with the SCO UnixWare/OpenServer Development Kit (UDK). This means that native methods cannot be built with the existing development kit on OpenServer or UnixWare 2.

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 X must reference X11R6 headers, since that is what the JDK AWT uses

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

Another important limitation with native methods is upon the kinds of system operations that a native method can do. In particular:

• a native method cannot make use of the threads library, libthread.so from UnixWare 2.1.2 or UnixWare 7.
• direct native methods access to commercial database systems is potentially hazardous due to inappropriate system-level usages by the DBMSes conflicting with the JVM; use JDBC instead

SCO-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 JDK 1.1.3 (in the jdk113pls package), under the subdirectories native_c_demo, jni_c_demo, native_c++_demo, and jni_c++_demo.

Debugging Native Methods

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

Debugging of C or C++ native methods, however, must be done with the UDK debugger. This section describes how to go about this.

One thing you'll notice is that after-the-fact core dumps from the JVM (which might be caused by a native method bug) are pretty useless, because the traceback comes from a JVM signal handler rather than from the real point of failure.

The solution to this is to run the application, i.e., the JVM, from within the debugger. Then when a segmentation violation occurs, for instance, the debugger will stop right there and the stack trace will be from the real point of failure.

In order to run the JVM from within the debugger, you need to invoke the JVM executable directly. First, you should run the java_g version of the JVM, since that contains debugging information. Second, if you look at /usr/java/bin/java_g, you'll see that it's a link to a script called .java_wrapper, that sets up the LD_LIBRARY_PATH and CLASSPATH environment variables before calling the actual JVM executable in /usr/java/bin/x86at/green_threads/java_g.

If you invoke /usr/java/bin/java_g through ksh -x you'll see the values LD_LIBRARY_PATH and CLASSPATH are set to; you can set those manually at the command line (store in a script that you "dot" if you debug frequently), then invoke the debugger:

$ . setup_java	# your script to set LD_LIBRARY_PATH and CLASSPATH
$ debug -ic	# or can use graphical version
debug> create /usr/java/bin/x86at/green_threads/java_g my_app
debug> run
debug>

Another complication sets in when you want to use symbols (to set breakpoints on, for instance) that are outside of the JVM, such as in native methods. The dynamic libraries that contain native methods are loaded by the JVM via the dlopen call, and until this happens, symbols in the native methods won't be visible to the debugger.

The solution to this is to set a breakpoint inside the JVM at the point where the dynamic library has been loaded, but before code in the libraries is called. For JDK 1.1.3 the appropriate breakpoint is linker_md.c@207. Here is an example demonstrating both the problem and the solution:

$ debug -ic
debug> create /usr/java/bin/x86at/green_threads/java_g my_app
debug> stop my_nativemethod_function
Error: No entry "my_nativemethod_function" exists

debug> stop linker_md.c@207
EVENT [1] assigned
debug> run
STOP EVENT TRIGGERED: linker_md.c@207  in p1 [sysAddDLSegment in ../../../../src/unixware/java/runtime/linker_md.c]
207:        dlsegment[useddlsegments].fname = strdup(fn);
debug> stop my_nativemethod_function
EVENT [2] assigned
debug> run
STOP EVENT TRIGGERED: my_nativemethod_function in p1 [my_nativemethod_function in myfile.C]
68:         bool finished = false;
debug>

If you do a lot of this kind of debugging it can be useful to set up an alias in your ~/.debugrc file:

alias cnm create /usr/java/bin/x86at/green_threads/java_g ; run -u linker_md.c@207

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 JDK 1.1.3 for SCO contains SCO's implementation of JDBC and includes the SCO JDBC driver. SCO's JDBC implementation is built upon SCO's SQL-Retriever product. For more information on SCO SQL-Retriever, please visit www.vision.sco.com .

There is no need to separately install the SCO JDBC implementation, since it is part of the jdk113 installation. It is necessary to separately install the SQL-Retriever product if you are interested in using JDBC.

Implementation Notes

System Properties

java.home=/usr/java
java.vendor=SCO
java.vendor.url=http://www.sco.com/
java.class.version=45.3

while here are values that are specific to OpenServer 5.0.4:

os.arch=IA32
os.name=OpenServer
os.version=5.0.4

UnixWare 2.1.2:

os.arch=IA32
os.name=UnixWare
os.version=2.1.2

and UnixWare 7:

os.arch=IA32
os.name=UnixWare
os.version=7

Abstract Windowing Toolkit

Threads

Performance

Conformance

Known Problems

1. On all three platforms, the X11R6 implementation is currently built to only use TCP/IP as a connection mechanism. This means that even when working locally, you need to issue an xhost +your_machine_name command.

2. On OpenServer (5.0.4) and UnixWare (2.1.2) when appletviewer or java are invoked you may see the following message which may be ignored:
   current locale is not supported in X11, locale is set to CX locale modifiers are not supported, using default

3. Large file support (for files > 2GB in size) is not yet present in the java.io package, or anywhere else in the JDK.

Copyright © 1998 The Santa Cruz Operation, Inc. All Rights Reserved.