These release notes support ptx® Server Environment for the JavaTM Platform (ptx/JSE) V3.0.2 on systems running DYNIX/ptx® V4.5.x or V4.6.x. ptx/JSE V3.0.2 is a maintenance release of the Java 2 SDK, Standard Edition, v1.2.2 from Sun Microsystems® for NUMA-Q® systems. Specifically, it contains bug fixes and improvements from Java 2 SDK v1.2.2_005. The Java 2 SDK is the development environment for building applications, applets, and components that can be deployed on the Java platform.
These release notes and the jse(1) man page are the only documentation provided for ptx/JSE. Sun Microsystems provides extensive HTML documentation at their Web site about the Java 2 SDK and the Java Platform. You should always refer first to these ptx/JSE release notes and then secondarily to the Sun HTML documentation. For more information about the jse(1) man page and the Sun HTML documentation, refer to "Product Documentation" later in these release notes.
Read these release notes before you install or run this release of ptx/JSE.
The changes in ptx/JSE V3.0.2 since ptx/JSE V3.0.1 are as follows:
ptx/JSE V3.0.2 is a port of the Java 2 SDK, Standard Edition, v1.2.2, patch 005, and contains all features and changes that Sun Microsystems included with their release. (ptx/JSE V3.0.1 is a port of the Java 2 SDK, V1.2.2, patch 004.)
For information on the changes between the Java 2 SDK, V1.2.1 and the Java 2 SDK, V1.2.2, refer to the Sun release notes at the following URL:
http://java.sun.com/products/jdk/1.2/changes.html
For information on the changes between the FCS version of the Java 2 SDK, V1.2.2 and the patch 005 version of the Java 2 SDK, V1.2.2, refer to the CHANGES file in the ptx/JSE installation directory, which by default is /opt/jse3.0.
ptx/JSE V3.0.2 consists of the entire SDK as defined by the Java 2 Platform API with no changes or extensions beyond those required to build and run the SDK on DYNIX/ptx. ptx/JSE V3.0.2 has passed 100% of the Java Compatibility Test Kit (JCK) as provided by Sun Microsystems. No performance enhancements have been made for DYNIX/ptx. Additionally, ptx/JSE does not contain a just-in-time compiler or a native compiler.
A summary of new features for the Java 2 SDK, Standard Edition,V1.2 is located at the following URL:
http://java.sun.com/products/jdk/1.2/docs/relnotes/features.html
If your site previously used ptx/JSE V1.1.x, you should refer to the following URL for migration issues between JDK 1.1 and the Java 2 SDK, v1.2:
The changes in ptx/JSE V3.0.1 since ptx/JSE V3.0.0 are as follows:
ptx/JSE V3.0.1 is a port of the Java 2 SDK, Standard Edition, v1.2.2, patch 004, and contains all features and changes that Sun Microsystems included with their release. (ptx/JSE V3.0.0 is a port of the Java 2 SDK, V1.2.1.)
With ptx/JSE V3.0.1, POSIX threads (native threads) can be used even when user-defined regions are activated on the host. (In ptx/JSE V3.0.0, POSIX threads could not be used when user-defined regions were activated on the host.) For limitations when using native threads and Application Regions, refer to the DYNIX/ptx System Configuration and Performance Guide. For more information on the Java threading options, refer to the Sun documentation at:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/solaris/threads.html
Two problems reported against ptx/JSE were fixed in ptx/JSE V3.0.1 For more information, refer to "Fixed Problems in ptx/JSE V3.0.1".
The changes in ptx/JSE V3.0.0 since ptx/JSE V1.2.1 are as follows:
ptx/JSE V3.0.0 is a port of the Java 2 SDK, Standard Edition, v1.2.1 and contains all features and changes that Sun Microsystems included with their release. Version 1.2 of the SDK offers significant improvements in functionality, performance, security, and global support.
ptx/JSE V3.0.0 consists of the entire SDK as defined by the Java 2 Platform API with no changes or extensions beyond those required to build and run the SDK on DYNIX/ptx. ptx/JSE V3.0.0 has passed 100% of the Java Compatibility Test Kit (JCK) as provided by Sun Microsystems. No performance enhancements have been made for DYNIX/ptx. Additionally, ptx/JSE does not contain a just-in-time compiler or a native compiler. ptx/JSE V3.0.0 is year 2000 compliant.
If your site previously used ptx/JSE V1.1.x, you should refer to the following URL for migration issues between JDK 1.1 and the Java 2 SDK, v1.2:
ptx/JSE V3.0.0 provides both POSIX threads, also known as native threads, and a user-level threading package provided by Sun®, also known as green threads. By default, ptx/JSE uses POSIX threads when there are no user-defined regions activated on the host. If user-defined regions are activated on the host, then by default ptx/JSE uses the user-level threading package. You can override these defaults if desired.
In ptx/JSE V3.0.0, swap space is only consumed as the Java application requires it. Previous releases of ptx/JSE preallocated the maximum size of the memory allocation pool when a Java application was started. This meant that JVM processes typically used more than 80 MB of swap space, even for very small applications. Now, the actual amount of swap space used for a given Java application depends on the complexity of the application. Swap space consumption could still expand to 80 MB for a complex Java application, but should be much less for simple Java applications.
The JVM uses assembly language for the core interpreter. This change has improved the performance of byte-code execution. Previous releases of ptx/JSE used the C language for the core interpreter.
The following change occurred in ptx/JSE V3.0.0 since ptx/JSE V1.1.2:
In ptx/JSE V3.0.0, the java tool is the Java application launcher provided in the Java run-time environment. Beginning with the Java 2 SDK, a single launcher is used both for development and deployment. The jre tool that was provided in ptx/JSE V1.1.x is no longer provided. The Java run-time environment is located under /opt/jse3.0/jre. The Java run-time environment can still be distributed with Java applications. Instead of starting applications with the jre command, users will now use the java command.
ptx/JSE V3.0.2 runs on DYNIX/ptx V4.5.x or V4.6.x. ptx/JSE requires the following software. Refer to the appropriate version of the DYNIX/ptx Release Notes for the versions of software that apply to your host.
Installing ptx/JSE requires approximately 75 MB. By default, ptx/JSE is installed in the root filesystem, but it can be installed in an alternate filesystem.
The amount of swap space you should allocate for each Java program that you run depends on the complexity of each application. Swap space consumption could still expand to 80 MB for a complex Java application, but should be much less for simple Java applications.
ptx/JSE is installed on DYNIX/ptx with the standard ptx/INSTALL installation process. For installation instructions, refer to the DYNIX/ptx V4.5.2 and Layered Products Software Installation Release Notes or the DYNIX/ptx V4.6.0 and Layered Products Software Installation Release Notes, as applicable.
ptx/JSE V3.0.2 is currently distributed on both the "DYNIX/ptx V4.5.2 Operating System and Layered Products, Volume 1" CD-ROM and the "DYNIX/ptx V4.6.0 Operating System and Layered Products, Volume 1" CD-ROM.
By default, ptx/JSE is installed in the root filesystem under /opt/jse3.0. Alternatively, you can install ptx/JSE in a different filesystem. If you do so, /opt/jse3.0 is created as a symbolic link to the actual installation directory.
After installation, for each user that is developing or running Java applications, update the PATH environment variable so that it includes the /opt/jse3.0/bin directory.
ptx/JSE includes the CLASSPATH environment variable, which tells the Java Virtual Machine (JVM) and other Java applications where to find the class libraries. To use ptx/JSE you need not set this environment variable. However, if you are building Java applications whose classes reside in a directory structure other than that of ptx/JSE, you must designate the directories that contain the appropriate classes in the CLASSPATH environment variable. If more than one directory is designated, use colons to separate the entries.
The setting of the CLASSPATH environment variable specifies the directories that are to be searched before the standard ptx/JSE class directories are searched.
Java commands are typically initiated by executing Korn shell scripts installed in $JAVA_HOME/bin. The values of environment variables such as CLASSPATH, JAVA_HOME, and LD_LIBRARY_PATH influence the behavior of the Java commands.
If the ENV environment variable is set to expand to the pathname of a script such as $HOME/.profile, undesirable side effects can occur because $HOME/.profile could alter the contents of environment variables used by the Java command scripts.
Prior to executing Java commands, remove the environment variable definitions from any scripts referenced by ENV, or set ENV to the null string as follows:
export ENV=""
ptx/JSE includes the following types of development tools:
Basic tools
Remote Method Invocation (RMI) tools
Internationalization tools
Security tools
Java Interface Definition Language (IDL) tools
The remainder of this discussion provides a brief introduction to each tool. Complete documentation on these tools and their options is available in the online Java 2 SDK Tools documentation, which is located at the following URL:
http://java.sun.com/products/jdk/1.2/docs/tooldocs/tools.html
The Solaris platform references apply to DYNIX/ptx platforms.
These tools are the foundation of the Java 2 SDK and are used to create and build applications.
Compiles programs written in the Java programming language into bytecodes. The syntax is as follows:
javac [ options ] [ sourcefiles ] [ @files ]
Launches Java applications. A single launcher is used both for development and deployment. (jre is no longer provided.) The syntax is as follows:
java [ threads_flag ] [ options ] class [ argument... ]
java [ threads_flag ] [ options ] -jar file.jar [ argument... ]
oldjava [ threads_flag ] [ options ] class [ argument... ]
Generates HTML pages of API documentation from Java source files. The syntax is as follows:
javadoc [ options ] [ packagenames | sourcefiles ] [ @files ]
Allows you to run applets without a Web browser. The syntax is as follows:
appletviewer [ threads_flag ] [ options ] urls...
Combines multiple files into a single Java Archive (JAR) file. The syntax is as follows:
jar [ options ] [ manifest ] destination input-file [ input-files ]
Debugs Java programs. jdb is a dbx-like command-line debugger for Java classes. The syntax is as follows:
jdb [ options ] [ class ] [ arguments ]
Creates C header files and C source files from a Java class. These files provide the connective glue that allows your code written in the Java Programming Language to interact with code written in other languages like C. The syntax is as follows:
javah [ options ] fully-qualified-classname ...
javah_g [ options ] fully-qualified-classname ...
javah_g is a non-optimized version of javah suitable for use with debuggers like jdb. The syntax for javah_g is similar to that of javah:
Disassembles compiled Java files and prints out a representation of the Java bytecodes. The syntax is as follows:
javap [ options ] class ...
Detects version conflicts between a target jar file and currently installed extension jar files.
extcheck [ -verbose ] targetfile,jar
These tools help to create applications that interact over the Web or other networks.
Generates stub and skeleton class files for Java objects implementing the java.rmi.Remote interface. The syntax is as follows:
rmic [ options ] package-qualified-class-name(s)
Starts a remote object registry on a specified port. The remote object registry is a bootstrap naming service which is used by RMI servers. The syntax is as follows:
rmiregistry [ port ]
Starts the RMI activation system daemon so that objects can be registered and activated in a Java virtual machine. The syntax is as follows:
rmid [ -port port [ -log directory ]
Returns the serialVersionUID for one or more classes. The syntax is as follows:
serialver [ options ] [ classnames ]
This tool helps to create applications that can be localized.
Converts non-Unicode Latin-1 (source code or property) files to Unicode Latin-1. The syntax is as follows:
native2ascii [ options ] [ inputfile [ outputfile ] ]
These tools help you set security policies on your system and create applications that can work within the scope of security policies set at remote sites.
Manages keystores (databases) of private keys and certificates. The syntax is as follows:
keytool [ commands ]
Generates and verifies archive file signatures. The syntax is as follows:
jarsigner [ options ] jar.file alias
jarsigner - verify [ options ] jar.file
Provides a graphical user interface for managing policy files. The syntax is as follows:
policytool
These tools are used when creating applications that use Common Object Request Broker Architecture (CORBA) to access databases. Refer to the Sun documentation for syntax and usage.
Provides access to the naming service.
Generates .java files that map an Object Management Group (OMG) interface definition language (IDL) interface and enable an application written in the Java programming language to use CORBA functionality. This tool is not part of the Java 2 SDK or ptx/JSE and currently is available only for Solaris® and Windows operating systems. It does not run on DYNIX/ptx. You can download idltojava from the Java IDL Web site at the following URL:
http://java.sun.com/products/jdk/idl/
ptx/JSE includes the demonstration applets and applications that are provided with the Java 2 SDK in the /opt/jse3.0/demo directory. For information about these demonstration applets and applications, refer to the following URL:
http://java.sun.com/products/jdk/1.2/docs/relnotes/demos.html
These release notes and the jse(1) man page are the only documentation provided specifically for ptx/JSE.
The jse(1) man page provides an overview of ptx/JSE. To view the jse man page, enter the command man jse at the DYNIX/ptx command line prompt.
Additionally, Sun Microsystems provides extensive HTML documentation at their Web site about the Java 2 SDK and the Java Platform. You should always refer first to these ptx/JSE release notes and then secondarily to the Sun HTML documentation.
The Java 2 SDK HTML documentation includes references to Solaris and Microsoft Windows platforms. The Solaris platform references apply to DYNIX/ptx platforms; the Windows references do not. Furthermore, references in the Sun documentation about downloading and installing the Java 2 SDK do not apply to ptx/JSE.
The most applicable Sun Microsystems Java Web sites are as follows:
The Java 2 SDK README file provides an introduction to the Java 2 SDK and numerous links to other Java 2 SDK pages. Refer to the following URL:
The complete Java 2 SDK 1.2.x documentation is located at the following URL:
The Java Platform Documentation Web page contains links to general documentation, product and API documentation, core technical reference documentation, policies, and helpful tips. Refer to the following URL:
Additional information about the Java technology and the SDK, including information about previous releases, is available from the Java Technology Home Page at the following URL:
For updates to the Sun documentation since the first release of the Java 2 SDK, refer to the following URL, which is maintained by Sun. Note that updates beyond Java 2 SDK 1.2.2-005 do not apply to ptx/JSE V3.0.2.
This section provides information on the following topics
Note that no problems were fixed in ptx/JSE V3.0.2 beyond the fixes that Sun provided in the Java 2 SDK, Standard Edition, V1.2.2_005. Additionally, no problems were fixed in ptx/JSE V3.0.0 beyond the fixes that Sun provided in the Java 2 SDK, Standard Edition, V1.2.1.
ptx/JSE V3.0.1 contains the following fixes since ptx/JSE V3.0.0 was released:
(248864, 251877) BufferedReader.readLine() incorrectly failed with java.io.IOException: Invalid argument errors.
(251464) The os.version property incorrectly returned the operating-system release. For example, it returned 4.0 as in UNIX System V Release 4.0. Now the os.version property returns the operating-system version, for example V4.5.1.
As a supported DYNIX/ptx customer, you should always call customer support with questions and to report problems. If you report a problem to customer support regarding running a bytecode file and the problem can be reproduced on another platform (such as Microsoft Windows), we will forward it to Sun and track resolution of the problem with Sun. If we determine that the problem is unique to ptx/JSE or DYNIX/ptx, then we will determine the resolution of the problem.
However, because ptx/JSE is a direct port of the Sun-provided Java 2 SDK, we cannot neither add to nor modify the behavior of the Java 2 SDK, including the API set. Any enhancement request of this nature given to us will be forwarded to Sun.
There are no problems currently reported against ptx/JSE.
For information on the problems reported to Sun Microsystems against the Java 2 SDK, you can register free online as a member of the Java Developer Connection and refer to the following URL:
http://developer.javasoft.com/developer/bugParade/index.html
This sections lists common questions and answers about ptx/JSE in the following areas:
Q: Why is the Java Language Debugger (jdb) not working properly? Why does it tell me it requires a password when I'm running it locally?
The Java Language Debugger (jdb) is launched from a script, which runs the rc file for your default shell. If that rc file starts other processes or is set to echo all script commands, the jdb will think you are starting it to debug one of the processes running remotely. Check your default rc file and make sure it is not starting such processes.
Q: Why do I keep getting failures trying to access shared objects or classes that I should have visibility to?
If your shared object files or class files are accessed over an automounted filesystem, the open call may be getting a SIGALRM failure because of the time it takes the automounter to open the files. Try accessing the files from a local or non-automounted filesystem.
Q: When I set the environment variable LC_CTYPE to any value (including English), why does it sometimes trigger a segfault in some Motif calls?
This is a problem (report 238425) in ptx/XWM, which is used by ptx/JSE. The workaround is to unset the LC_CTYPE environment variable.
Q. What happens if I try to use the audio application programming interface (API)?
A message is generated when the audio implementation cannot find a sound card on the NUMA-Q system. Otherwise, the application or applet should run normally. The message generated by Java 2 SDK on any platform without a sound card is the following:
audio device busy (attempt 1 out of 5)
audio player exit
Q: When using green threads, why are system calls from Java native methods problematic when more than one thread simultaneously calls the same function?
DYNIX/ptx V4.5.x system libraries are not thread-safe when used by the green threads package. For this reason, system calls from Java native methods can be problematic when more than one thread simultaneously calls the same thread-unsafe function. You can improve the situation in one of two ways: either avoid concurrent execution of native methods from multiple threads, or provide a mutual exclusion mechanism to prevent simultaneous calls.
Q: Why am I getting connect errors when I try to use sockets in a native method?
If you write native methods that make calls on sockets or call methods in a Java API that uses sockets, those native methods must be compiled to use BSD sockets and not ABI sockets. This is because the Java Virtual Machine (JVM) is compiled with BSD sockets.
Q: Are there any other problems that I might encounter when writing native methods?
It is possible to get different results from mathematical expressions in a native method than you would get in the Java Virtual Machine (JVM) when dealing with divide-by-zero, remainder-by-zero, square root of negative numbers, rollover from INT_MAX and INT_MIN, not-a-number, infinity, or negative zero. This is because the JVM has explicitly-defined behavior under these "edge conditions" which may differ from some C compiler implementations.
Q. Why does the JVM fail with a segmentation violation during execution of a Java native method?
The Java Virtual Machine (JVM) executable is linked using the ld(1) command with the -z nopage0 option. This option tells ld not to bind anything to address zero, which will allow runtime detection of null pointers. However, null pointer references from Java native methods will cause the JVM to terminate due to a segmentation violation. Developers should take care to avoid null pointer references in Java native method code. If Java native method code is tested from executables other than the JVM, the executables should be linked with -z nopage0 to ensure early detection of null pointer references.
Q: Why are my Java-based GUIs displayed improperly?
The Java Abstract Windows Toolkit (AWT) on UNIX platforms is built on top of Motif® and X Windows. For this reason, you may need to experiment with the settings in the X Windows resource files (.Xdefaults file and .xsession file) to get the desired GUI display. For example, in some cases, the setting of the borderWidth resource has been seen to affect the display of Java GUIs.
Appearance problems that you see in Java GUIs are generally X Windows issues. For example, an X Windows issue is a GUI element not appearing in the desired location. On the other hand, functionality problems are usually Java issues, and not X Windows related. An example of a Java issue is when data cannot be entered into a GUI element.
If you are using Exceed®, make sure you are running one of the more current versions, which is at least Exceed V5.1.3 or later. Earlier versions of Exceed that were using multiple-window mode have been seen to improperly display Java GUIs.
Q: Why is the color red not displayed and the green and blue colors reversed when GUI objects are built with the Abstract Window Toolkit (AWT)?
Check the color display settings on your user interface device. If you are using 16-bit color, using either 256 colors or 24-bit color settings instead should clear up the problem.
Q: Why do my Java-based applications hang when run on an X terminal?
The Java 2 SDK code from Sun Microsystems does not support the use of some X terminals. For this reason, ptx/JSE does not support X terminals.