JavaTM 2, Standard Edition 5.0, update 15
for
SCO® UNIX® Operating Systems
FCS - UnixWare 7.1.4
FCS - OpenServer 6.0.0
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:
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 MicrosystemsTM Java 2 Platform - the technology and environment described in the SunTM specifications of the Java 2 Standard Edition, 5.0 update 15. (The "update 15" 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.
| Software: |
Supported SCO UNIX platforms:
|
| RAM: | 256 MB |
| Disk Space: | Minimum 114 MB |
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.
J2SE 5.0, update 15
J2SE 5.0, update 15 for SCO UNIX encompasses the changes and security fixes from Sun's J2SE 5.0, updates 10 through 15. In addition the timezone changes for Western Australia (Perth) released as a patch for J2SE 5.0, update 09 and J2SE 1.4.2.13 and earlier have been encorporated into this release.Automatic update of the
/usr/javaand/usr/java2symbolic links to the installation of this J2SE release has changed. Please see the "Installations Location and Multiple Java Versions" subsection of these J2SE 5.0, update 15 Release Notes for complete details.The J2SE 5.0, update 15 release supercedes the J2SE 5.0, update 09 previously released on the SCO Support web site.
Sun Alert ID Description 233321 Two security vulnerabilities in the Java Runtime Environment Virtual Machine may independently allow an untrusted application or applet that is downloaded from a website to elevate its privileges. For example, the application or applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted application or applet. 233322 A security vulnerability in the Java Runtime Environment (JRE) with the processing of XSLT transformations may allow an untrusted applet or application that is downloaded from a website to elevate its privileges. For example, an applet may read certain unauthorized URL resources (such as some files and web pages) or potentially execute arbitrary code. This vulnerability may also be exploited to create a Denial-of-Service (DoS) condition by causing the JRE to crash. 233324 A security vulnerability in the Java Plug-in may allow an applet that is downloaded from a website to bypass the same origin policy and leverage this flaw to execute local applications that are accessible to the user running the untrusted applet. 233325 A vulnerability in the Java Runtime Environment image parsing library may allow an untrusted application or applet that is downloaded from a website to elevate its privileges. For example, the application or applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted application or applet.
Two vulnerabilities in the color management library may allow an untrusted applet or application or applet to cause the Java Runtime Environment to crash, which is a type of Denial of Service (DoS).233326 A vulnerability in the Java Runtime Environment may allow JavaScript code that is downloaded by a browser to make connections to network services on the system that the browser runs on, through Java APIs. This may allow files (that are accessible through these network services) or vulnerabilities (that exist on these network services) which are not otherwise normally accessible to be accessed or exploited. 200040
(103112)A vulnerability in the Virtual Machine of the Java Runtime Environment may allow an untrusted applet to elevate its privileges. For example, an applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted applet. 201519
(103079)A vulnerability in the Java Runtime Environment (JRE) with applet caching may allow an untrusted applet that is downloaded from a malicious website to make network connections to network services on machines other than the one that the applet was downloaded from. This may allow network resources (such as web pages) and vulnerabilities (that exist on these network services) which are not otherwise normally accessible to be accessed or exploited. 200041
(103078)A vulnerability in the Java Runtime Environment (JRE) may allow malicious Javascript code that is downloaded by a browser from a malicious website to make network connections, through Java APIs, to network services on machines other than the one that the Javascript code was downloaded from. This may allow network resources (such as web pages) and vulnerabilities (that exist on these network services) which are not otherwise normally accessible to be accessed or exploited.
A second vulnerability in the JRE may allow an untrusted applet that is downloaded from a malicious website through a web proxy to make network connections to network services on machines other than the one that the applet was downloaded from. This may allow network resources (such as web pages) and vulnerabilities (that exist on these network services) which are not otherwise normally accessible to be accessed or exploited.200162
(103072)A vulnerability in the Java Runtime Environment may allow an untrusted Java Web Start application or Java applet to move or copy arbitrary files on the system that the application or applet runs on, by requesting the user of the application or applet to drag a file from the application or applet window to a desktop application that has permissions to accept and write files on the system. To exploit this vulnerability, the application or applet has to successfully persuade the user to drag and drop the file. 200837
(103071)When an untrusted applet or application displays a window, the Java Runtime Environment includes a warning banner inside the window to indicate that the applet or application is untrusted. A defect in the Java Runtime Environment may allow an untrusted applet or application that is downloaded from a malicious website to display a window that exceeds the size of a user's screen so that the warning banner is not visible to the user. 200392
(103024)A vulnerability in the font parsing code in the Java Runtime Environment may allow an untrusted applet to elevate its privileges. For example, an applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted applet. 200599
(102997)The Java Secure Socket Extension (JSSE) that is included in various releases of the Java Runtime Environment does not correctly process SSL/TLS handshake requests. This vulnerability may be exploited to create a Denial of Service (DoS) condition to the system as a whole on a server that listens for SSL/TLS connections using JSSE for SSL/TLS support. 201551
(102995)A security vulnerability in the Java Runtime Environment Applet Class Loader may allow an untrusted applet that is loaded from a remote system to circumvent network access restrictions and establish socket connections to certain services running on the local host, as if it were loaded from the system that the applet is running on. This may allow the untrusted remote applet the ability to exploit any security vulnerabilities existing in the services it has connected to. 201348
(102958)A defect in the Javadoc tool in various releases of the JDK may lead to the generation of HTML documentation pages which contain a potential cross-site scripting (XSS) vulnerability. This may allow a remote user to gain access to cookies from the website that hosts the generated documentation. 200856
(102934)A buffer overflow vulnerability in the image parsing code in the Java Runtime Environment may allow an untrusted applet or application to elevate its privileges. For example, an applet may grant itself permissions to read and write local files or execute local applications that are accessible to the user running the untrusted applet.
A second vulnerability may allow an untrusted applet or application to cause the Java Virtual Machine to hang.200074
(102760)A buffer overflow vulnerability in processing GIF images in the Java Runtime Environment may allow an untrusted applet to elevate its privileges. For example, an applet may grant itself permissions to read and write local files or execute local applications with the privileges of the user running the untrusted applet. For more information see:
http://www.zerodayinitiative.com/advisories/ZDI-07-005.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0234Security fixes that have been announced by Sun, but have been released in earlier releases, have been added to the securiy fix list in the J2SE 5.0, update 9 changes.
J2SE 5.0, update 09d
This release of J2SE 5.0, update 09d, in the OpenServer 6.0.0, Maintenance Pack 3, contains a fix to restore execution permission to the javap command and removes the javasoap package from the Java 5.0 component. Any pieces of the former javasoap package that are needed by Tomcat are now installed with Tomcat.
J2SE 5.0, update 09b
This web-release of J2SE 5.0, update 09b, contains a fix to avoid a bug on SCO platforms in the parallel garbage collection routines encountered when running JBoss on "server class" systems. This update is a minimum requirment for the SCO Me Inc. Mobility Server on OpenServer 6.0.0.
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 102760 A buffer overflow vulnerability in processing GIF images in the Java Runtime Environment may allow an untrusted applet to elevate its privileges. (Fix from J2SE 5.0, update 10 released in SCO's J2SE 5.0, update 09 release.) 102732 Two vulnerabilities in the Java Runtime Environment may allow an untrusted applet to access data in other applets. 102731 Two vulnerabilities related to serialization in the Java Runtime Environment may independently allow an untrusted applet or application to elevate its previleges. 102729 Two buffer overflow vulneribilities in the JRE may independently allow an untrusted applet to elevate its previleges. For example, an applet may grant itself permissions to read and write a local file or execute local applications that are accessible to the user running the untrusted applet. 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:
THREADS_FLAG
environment variable is no longer used.
JVM_USE_RDTSC environment variable
is no longer used.
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.
Pkg/Cmpnt Name Required Software Approx. Size Contains j2jre150UW 7.1.4 72 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.
j2sdk150j2jre150 41 MB Development Tools:
appletviewer, the Java Applet Viewer;javac, the Java Compiler;jdb, the command-line Java debugger;javah, the C Header and Stub File Generator for native methods;javap, the Java Class File Disassembler;javadoc, the JAVA API Documentation Generator;jar, the Java Archive (JAR) tool; and assorted other commands used in Java development; class libraries used in Java development; header files used in native code development. Also Java demo applets and applications; demos of Swing functionality; native method demos; Java Plugin demos.
j2plg150j2jre150 .5 MB Java 2 Plugin for Mozilla browser 1.7.x on UnixWare 7.1.4 and OpenServer 6.0.0. j2se150OSR 6.0.0 116 MB In additional to the Runtime Support, Development Tools and Java Plugin software in the UnixWare packages above, the OpenServer 6.0.0 product contains the additional software whose JNI runtime or JAR files must be installed in the J2SE 5.0 product repository.
- Java Communications API (javaxcomm)
- Apache Axis SOAP Web Services 1.2 & Apache Xerces-J XML Parser 1.4.4
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.
/opt.
J2SE 1.3.1 ==>Updates to each major version of J2SE install in the same base directory./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:
JAVA_HOME that points to
/usr/java or directly to the installation directory
/opt/java2-1.x.x.
/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.
j2se150 component for OpenServer 6.0.0 is an all inclusive
J2SE 5.0 release including other Java packages. It contains the JRE, SDK
and Java Plugin packages as well as the javaxcomm(java serial I/O support) package.
As of J2SE 5.0_09d, the javasoap package, formerly installed with J2SE 5.0, is
no longer needed. Any necessary pieces needed by Tomcat are installed with the Tomcat component.
If using the images on the SCO Product Download site, first download the following image:
mkdir JAVA150Run the Software Manager with the command:
cd JAVA150; tar -xf ../OSR6_Java2_150.VOLS.tar
scoadmin softwareor double-click on the Software Manager icon in the desktop.
or
custom
/usr/java symbolic link.
If using the images on the SCO Product Download site, first download the following imags:
zcat j2jre150.ds.Z | pkgadd -d - allIf the package datastreams have been uncompressed when downloaded with your browser:
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
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.
/usr/java and /usr/java2 symbolic
links will be created if they do not currently exist on your system.
They will also be updated if they currently point to an earlier version
of Java such as J2SE 1.3.1 or 1.4.2.
The symbolic links will not be altered if they currently point to a later release of Java such as J2SE 1.6.0.
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.
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
the javaxcomm package. The javasoap package is no longer
associated directly with the J2SE 5.0 component.
Instead, you may browse Sun's complete JDKTM 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 "SolarisTM" version (not the "LinuxTM" 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.
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.
In this release of J2SE 5.0, the SCO extension to treat Java
classes as first-class executables, available in J2SE 1.4.2 and earlier
releases, is not available. The feature requires an update to the
system command /bin/javaexecto recognize J2SE 5.0
as a valid Java first-class executable. An SLS for OpenServer 6.0.0 or
a PTF for UnixWare 7.1.4 along with J2SE 5.0, update 08, each
scheduled for release around the end of September 2006 will enable
the Java classes as first-class executables enhancement.
Check the release notes of the SLS or PTF for availability of the
updated /bin/javaexec command.
Once J2SE 5.0 has been installed, attempts to use this feature for Java classes compiled with earlier Java releases may fail with:
javaexec: directory: Error 0
This happens because the default Java PATH, /usr/java, now
points to the J2SE 5.0 installation path which is not recognized by
javaexec as a valid, functional SCO release. This problem can
be corrected by either:
JAVA_HOME in your environment to point to
the version of J2SE to be used, i.e. /opt/java2-1.4.2
/usr/java symbolic link to point to your
previous J2SE release. J2SE 5.0 can still be accessed through
/usr/java2
Of course, you can always use the traditional way of executing a Java application:
In this case,$ java foo
java must be in the PATH,
and foo.class must be in the CLASSPATH.
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:
java -XX:+PrintCompilation option.
java -Xcomp option.
java -Xint option.
java -XX:CompileOnly=name,name,... option,
where the argument is a series of comma-separated
package-name.class-name.method-name names.
java -XX:CompilerThreadPriority=n option,
where n is an operating system priority significantly
higher or lower than the default value of 96.
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.
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:
long long data type,
to match the Java 64-bit long data type
libC.so) rather than an archive (libC.a)
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.
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.
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 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
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.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:
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 debuggerdebug> 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 ...
stack command on that thread:
and voila we have both the Java stack and the native code stack for a given Java 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]
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.
System.Properties
can be queried. Here are some of the values that will be returned
by default on all
SCO UNIX platforms:
java.home=/opt/java2-1.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
SIGUSR1
and SIGUSR2 operating system
signals in its implementation of Java threads. User-written JNI code
should either:
SIGUSR1 or SIGUSR2
-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.
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 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.
jre/lib/fonts installation directory. On OpenServer this would
be in the custom component SSO directory tree, not the user visible
location in
serif,
sanserif,
monospaced,
dialog
and
dialoginput
are mapped to the available physical fonts by the font configuration file(s)
located in jre/lib/. The name and format of that file has
changed from that used in previous J2SE releases;
font.properties* files are no longer used.
The predefined font configuration file, fontconfig.bfc is
a binary format font configuration using only the Lucida fonts that come
with the Sun J2SE product. That configuration source is in the file
fontconfig.properties.src.
For complete details on font configuration, usage and issues see the relevant Sun documentation:
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.
xhost +your_machine_name command.
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.)
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.
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.
Copyright © 2006-2008 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.
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.
Mozilla and Firefox are trademarks of the Mozilla Foundation (mozilla.org).
UNIX and Motif are registered trademarks of The Open Group in the United States and other countries. Intel is a registered trademark of Intel Corporation. Netscape, Netscape Navigator, and Netscape Communicator are registered trademarks of Netscape Communications Corporation in the United States and other countries. NonStop is a registered trademark of Compaq Computer Corporation. X Window System is a trademark of the Massachusetts Institute of Technology. Apache is a trademark of the Apache Software Foundation. IBM is a registered trademark of the International Business Machines Corporation in the United States and other countries. Linux is a registered trademark of Linus Torvalds.
The SCO Group, Inc. reserves the right to change or modify any of the product or service specifications or features described herein without notice. This document is for information only. No express or implied representations or warranties are made in this document.