NonStop Server for Java 7.0 Programmer's Reference

When you follow this recommendation, you must include the JAR files of the Java based product
in either your CLASSPATH environment variable setting, or the -classpath (-cp) command-line
argument.
User-provided JAR files
Previously, JAR files were installed in (/usr/tandem/java/jre/lib/ext) because you did
not have to include such JAR files in the CLASSPATH. Starting with first version of NSJ4 (based on
J2SESDK 1.4.0), HP recommends that you to not install user-provided JAR files in any directory of
versions 1 and 2 of NSJ4 tree. You must leave the JAR files in user-specific directories. If you follow
this recommendation, you will not have to reinstall user-provided JAR files for new product releases
of NSJ4. However, you have to place the JAR files in the CLASSPATH.
Dynamic link libraries
On the TNS/E systems, NSJ 4, 5, 5.1, 6.0, and 7.0 support DLLs. All NonStop Server for Java
applications migrating from TNS/R to TNS/E must convert native libraries to DLLs.
Consider the following issues when migrating applications to use DLLs with NSJ7:
• All the Java libraries are built as DLLs.
• When using the JNI code, use DLLs instead of static libraries. For more information, see “Java
native interface (JNI)” (page 35). A public library directory does not apply for Java applications
on the TNS/E system.
• All DLLs must be in the files that have specific naming requirements.
• On TNS/E, the -Dcompaq.liblist option is not supported.
• The customer Makefile no longer exists in NSJ versions 4, 5, 5.1, 6.0, and 7.0 on TNS/E
because DLL support precludes the need to bind user native code in the Java executable.
• The _RLD_LIB_PATH environment variable, used only on the TNS/E system, specifies the
library path for user DLLs. For more information, see “_RLD_LIB_PATH” (page 26).
• The invocation API uses the JVM as a DLL; therefore, if you use this API, you do not need to
statically link Java to your programs.
Makefile to link native libraries
The customer Makefile no longer exists for NSJ versions 4, 5, 5.1, 6.0, and 7.0 on TNS/E because
DLL support precludes the need to bind user native code to the Java executable. For more information
about migrating native libraries, see “Dynamic link libraries” (page 93).
Compiling C++ native code
For TNS/E, C++ code is compiled using either version 2 or version 3 for user DLLs because the
NSJ versions 4, 5, 5.1, 6.0, and 7.0 on TNS/E is built with a C++ version neutral flag (the
-setCPlusPlusDialect neutral option for the linker).
If you are migrating NSJ applications based on JDK 1.3.x or earlier, you might need to change
your source code. Whether your native code needs source-code changes, depends on whether
the code uses C++ features that have changed in version 3. To identify required source-code
changes, run a migration check on your source code on TNS/R by invoking the version 2 compiler
and using the pragma MIGRATION_CHECK. Running this migration check causes the compiler to
issue a warning when a class or member function is present that has changed or become obsolete
for version 3. For more information about this pragma and the warnings it can produce, see C/C++
Programmers Guide.
Note that the VERSION3 directive specifies the use of the Standard C++ Library ISO/IEC version
3 and the C++ Standard headers. VERSION3 enforces the ISO/IEC IS 14882:1998 standard for
C++. The ISO C++ standard is identical to the ANSI C++ standard.
Summary of migration changes 93