|
|
United States-English | |
|
|
 |
|
User GuideJ2SE™ Development Kit (JDK) 5.0xfor the OpenVMS Operating System for the Java™ Platform |
|
*A good number for Setting Up the Java EnvironmentOn OpenVMS, you run a version-specific command procedure to set up the Java environment:
where x is the specific version number of the release you are using. Note: For simplicity, this document assumes you
installed the JDK using the default location and therefore references
Note: Starting with JDK 5.0-1, the JDK must be installed on an ODS-5 formatted disk. See 'Installing the kit' in the Release Notes for details on how to control where the kit is installed.
The following two command procedures may assist you in your initial
set-up of minimal quotas for using the Java programming language
on OpenVMS. The files help you determine whether you are set up
to run the Java programming language (quota-wise) and to generate
a configuration file of The first command procedure can be found in:
When you execute the following procedure:
you are asked several questions about your environment and the Java application you intend to run. Based on your answers, it generates a command procedure file (called
The second command procedure can be found in:
When you execute the following procedure:
it tests the process quotas in the current process and warns you if some of your account and sysgen quotas are not up to recommended level for running Java programs. The following example illustrates a typical pattern for using these command procedures:
Note: If you choose to run Switching VersionsYou can have multiple JDK versions installed on your OpenVMS system, and you can change from one to the other. The following sections describe how to do this. Note: For simplicity, this document assumes you
installed the JDK using the default location and therefore references
In Separate ProcessesTo use different JDK versions in separate processes, you must first run a command procedure to set up the Java environment definitions for the version of the JDK you want to use in the given process. The command procedures to perform the Java environment setup are version-specific, and are as follows:
For example, to run JDK 5.0, first run the following command file in your process: $ @SYS$COMMON:[JAVA$150.COM]JAVA$150_SETUP.COM alpha only You can select either the Fast VM or the classic VM as your virtual machine using this command file. Refer to Alpha Implementation to set up the Java environment. Note: To run the Fast VM with SDK v 1.3.0 or SDK v 1.2.2, you must install the appropriate version of Fast VM separately; it is not included on these kits. The Fast VM is not available for SDK v 1.1.8. Refer to our Software download page for product listing. In the Same ProcessTo use different JDK versions in the same process, you must first run a command procedure to cancel the Java environment definitions of one version of the JDK before setting up the environment of another version of the JDK. The command procedures to accomplish the Java environment cleanup are version-specific, and are as follows:
Once you have cancelled the Java environment, you must then run a command procedure to set up the Java environment definitions for the version of the JDK you want to use. For a list of these command procedures, see In Separate Processes. For example, to switch from using SDK v 1.3.1 to using SDK v 1.4.2 in the same process, run the following command procedures:
Running Starting with SDK v 1.4.2, the
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
OpenVMS Usage |
Explanation |
|
|
All files read by Java code ( |
| Role of |
A number of tools rely on either a |
| Quoting Operand |
Certain operands need to be quoted; Java tools are case-sensitive throughout their operation. Command-line operands are automatically lower-cased as they are acquired from the command line. In order to preserve the case so that these operands are acceptable to Java commands, you must quote them. The most common instances of this are:
See One-to-One Relationship Between Class Names and File Names for further discussion and examples of where quoting is needed. |
| Combating limitations on DCL command-line length |
DCL command-line length is limited. Constructing longer command lines is frequently convenient (and sometimes necessary). For example, you cannot build command lines like the following, if they exceed the character limit:: To work around this limitation on the OpenVMS Operating System,
the RTE has been customized to allow you to place operands
into a data file and then simply point to the data file on
the command line. The For example, you can write the following: where
Another usage is:
Note that operands on the command line need to be in quotation
marks to keep DCL from uppercasing the arguments, but the
same arguments in a file do not need to be in quotes because
they are not directly interpreted by DCL. File names appearing
in the input file specified by Also, on OpenVMS, you can use
where You can use
Note: The existence or accessibility of
the file specified by |
| If, within the data file used as input to
For example, the quoted argument on the following command line
will work. The arguments will be interpreted as:
If you put the parameters into a data file called
and then access them via:
they will be interpreted as:
The white space breaks up the processing of the line. Even if you enclose the operand in quotes, as in a data file
called
and then access them via:
they will be interpreted as:
The white space still breaks up the processing of the line. Note that the quotation marks are retained. The $ define/job JAVA$DISABLE_CMDFILE_WHITESPACE_PARSING TRUE
When this logical is defined, spaces and tabs are
no longer treated as delimiters in " Note: If the line contains a space, this space will be included as part of the command argument. For example, in:
Without the logical With the logical You can use the Alternatively, you can provide these parameters on the command line itself. |
|
| Dealing with UNIX-style filenames that cannot be represented on OpenVMS |
The OpenVMS file system on ODS-2
formatted disks cannot represent certain legitimate UNIX-style
file names; for example, a file named On OpenVMS, the JRE supports a filename remapping strategy
that allows you to represent otherwise-unrepresentable filenames
via a filename-mapping capability. This allows you to specify,
for example, that all filenames presented with multiple dots
in their names should be stored and retrieved as if all of
the dots, except the last, have been replaced by underscores;
hence the file above would be methodically read and written
as if it were named To learn more about other possible filename mappings, see UNIX Style Filenames on OpenVMS Systems. |
| Specifying multiple paths using the UNIX file path syntax |
The parsing of the values for
the switches If a path specified by one of these switches contains mixed OpenVMS and UNIX-style path syntax, an error will be displayed. |
| Getting around limitation of directory depth of 8 on ODS-2 disks |
The OpenVMS file structure on ODS-2 formatted disks limits you to only eight levels of directories. It is not uncommon for Java programs imported from elsewhere to have a package structure that is more than eight levels deep. To circumvent these limitations on OpenVMS, the JRE supports a filename remapping strategy that allows you to represent the deeper structure in a more shallow directory. Refer to Description of Mapping Options to see how this is accomplished. |
| Approximating Functionality That Does Not Exist: dlopen, dlsym, and dlclose |
OpenVMS systems do not have a
Example: The Java Zip library needs On OpenVMS systems, because |
The following functionalities either work differently on other platforms than they do on OpenVMS, or OpenVMS does not support them.
On OpenVMS, you set up the virtual machine in advance. There are differences between the virtual machines on different platforms. For more information, see I64 Implementation and Alpha Implementation.
Javald has not been ported to the JDK 5.0x for OpenVMS.
Java Sound is not supported. The following error is reported if you attempt to use Java Sound:
Java Sound support not currently available
^\ to Print Out Java StackOn OpenVMS systems, the RTE does not support the use of typing
^\ to get a printout of the Java stack. For more information,
refer to JAVA$ENABLE_SIGQUIT_CTRLC
and JAVA$ENABLE_SIGQUIT_MAILBOX.
seek() BehaviorWhen seeking beyond the end of a file, the default behavior of the C RTL is to physically extend the file. Depending on the offset specified in the seek operation, this can take a long time. This behavior differs from most UNIX systems, where the file is only extended if you write to it after the seek operation.
To enable the UNIX behavior on OpenVMS systems, uncomment the definition
of the DECC$POSIX_SEEK_STREAM_FILE logical in the JAVA$15x_SETUP.COM
file, where x is the specific version number of the release
you are using.
On OpenVMS systems, TCP/IP allows multiple listeners to bind to the same socket. This behavior is different from that exhibited on some other operating systems, where this phenomenon is detected and the following exception is thrown:
"java.net.BindException: Address already in use"
This is not a behavior specific to the RTE, but the way that TCP/IP Services works on OpenVMS systems. This difference is noted to caution you from relying on this exception if you intend to write portable Java applications.
Javadoc
Fails to Distinguish Class and Package Names in the Same DirectoryJavadoc fails to distinguish class and package names
that reside in the same directory and differ only in case. An example
is the package java.awt.event and the class java.awt.Event.
All Java files that are to be read by any of the Java tools or that serve as input class libraries (listed in CLASSPATH) must be in Stream_LF format. Stream_LF format is required for all data files read or written by Java programs.
To determine the record format of your file, do the following:
$ DIR/FULL MyFile.java
And observe the line:
Record format:
By default, a file initially created on an OpenVMS system, with a text editor for example, will have 'Variable length' record format.
Although a *.java file with 'Variable length' record
format compiles correctly if it is error-free, the compiler does
not produce proper diagnostic outputs if a compilation error occurs.
On OpenVMS, when you create a new version of an existing file,
the new file will inherit the record format of the existing file.
The record format preferred/required by the RTE is Stream_LF.
The RTE allows you to specify a logical:
$
DEFINE JAVA$CREATE_STMLF_FORMAT TRUE
With this logical defined, the RTE will force any newly-created
file to have a Stream_LF format. This allows the RTE
to override the C Run-Time Library's default of inheriting existing
file format from previous versions, which might not behave correctly
with the RTE.
To get an ASCII file into Stream_LF record format, do the following:
$ CONVERT/FDL=SYS$COMMON:[JAVA$15x.COM]STREAM_LF.FDL
input_filename -
output_filename
where x is the specific version number of the release
you are using, and where STREAM_LF.FDL is:
FILE
ALLOCATION 4
BEST_TRY_CONTIGUOUS yes
EXTENSION 0
ORGANIZATION sequential
RECORD
BLOCK_SPAN yes
FORMAT stream_LF
SIZE 0
If the file is in the proper format (Stream_LF), you will see the source error line printed out, with a carat (^) indicating the point of error:
$ javac "Bounce.java"
Bounce.java:11: Superclass smith.java.applet.Applet of class Bounce
not found.
public class Bounce extends smith.java.applet.Applet implements
Runnable
^
1 error
If the file is not in Stream_LF format, a blank line is printed instead of the source error line, and the carat position is not useful:
$ javac "Bounce.java"
Bounce.java:10: Superclass smith.java.applet.Applet of class Bounce
not found.
^
1 error
Binary .class files need to be Stream_LF as well.
If they are not Stream_LF you will get error messages like the following,
even though your CLASSPATH is correct and the correct
.class file is on the path:
Can't find class Test.HelloWorld
If you import .class files from a non-OpenVMS system,
be sure to convert them to Stream_LF.
To get a binary file (.class, .jar, .zip)
into Stream_LF record format, do the following to give the file
the right record format attributes:
$ SET FILE/ATTR=(RFM:STMLF,RAT:CR) filespec
JAVA$SHOW_FILENAME_MAPPING
for a trace of filename translation.There are a number of issues trying to represent UNIX directory and file specifications on an OpenVMS system. If you try to run a Java application developed elsewhere on an OpenVMS system, you might encounter problems with file and directory names.
The RTE provides a number of mapping algorithms that try to make a UNIX-style name usable under an OpenVMS file system.
These algorithms can be used in combinations. You can enable the use of each algorithm by turning on a particular bit in the following logical name:
JAVA$FILENAME_CONTROLS
To change the JAVA$FILENAME_CONTROLS default values,
edit the file: SYS$COMMON:[JAVA$15x.COM]JAVA$FILENAME_CONTROLS.COM
where x is the specific version number of the release you are using.
This file is called by JAVA$15x_SETUP.COM
to establish these and other defaults.
We suggest that you start off using this file as-is to enable all algorithms.
Different users may want to read/edit this file to enable/disable different algorithms to avoid selected problems.
The algorithms and the bit values to set them are summarized below.
A more detailed explanation of each option follows the table.
Current Filename Mapping |
|
Option Name |
Value |
| Support UNIX and OpenVMS filename | %x00000008 |
| Support dir in the filename | %x00000200 |
| Support valid characters in filename | %x00001000 |
Support hidden filename (replace with _) |
%x00004000 |
Support hidden filename (remove the .) |
%x00008000 |
Support multi dot in directory (replace with _) |
%x00020000 |
| Support multi dot in directory (remove dots) | %x00040000 |
| Support multi dot in file, keeping last | %x00100000 |
| Support multi dot in file, keeping first | %x00200000 |
| Support more than 39 characters by truncation | %x04000000 |
| Support more than 39 characters by moving the dot | %x08000000 |
| Support directory remapping | %x20000000 |
To see individual filename mappings as they occur, define the logical
JAVA$SHOW_FILENAME_MAPPING:
$ DEFINE JAVA$SHOW_FILENAME_MAPPING 1
This is useful if you are experiencing problems with the way filenames are being mapped, perhaps resulting in unexpected "File not found" messages.
To enable "UNIX and VMS" and "Multi dot first" you must issue the
following DEFINE:
$ FILE_MASK = %x00000008 + %x00200000
$ DEFINE JAVA$FILENAME_CONTROLS 'file_mask'
The options are processed at runtime in order from smallest to largest values.
Therefore, in this example, first "UNIX and VMS" would be processed, and then "Multi dot first".
To enable all the options:
$ DEFINE JAVA$FILENAME_CONTROLS -1
If JAVA$FILENAME_CONTROLS is not defined or is equal
to zero, then no mappings are attempted.
The following sections further describe the available mapping options.
Use this to map a mix of UNIX and OpenVMS filenames into UNIX-style names.
For example, a name like:
$disk1:[smith]/test.jtjtj/test.jtjtj
maps into:
/$disk1/smith/test.jtjtj/test.jtjtj
Change names of the form xxx.dir to their UNIX directory
counterpart.
For example, a name like:
/dkb500/smith.dir/testing.dat
maps into:
/dkb500/smith/testing.dat
Characters that can occur in UNIX-style names but are prohibited
in OpenVMS-style names are replaced by underscores (_),
unless these characters have special meaning in the UNIX-style name.
In that case, we attempt to map the special meaning.
For example, "~" refers to SYS$LOGIN.
The list of characters contains characters like "+".
No uppercasing is done. C will create/open the correct file.
_)Some Java applications expect to be able to create a hidden file
or directory. The hidden character "." will be replaced
by the "_" character.
For example, a name like:
.hotjava
maps into:
_hotjava
Or, a name like:
test/.hotjava/appletviewer.dat
maps into:
test/_hotjava/appletviewer.dat
Some Java applications expect to be able to create a hidden file or directory. The hidden character "." will be removed from the filename.
For example, a name like:
.hotjava
maps into:
hotjava
Or, a name like:
test/.hotjava/appletviewer.dat
maps into:
test/hotjava/appletviewer.dat
Multiple dots in directories are replaced with underscores.
For example, a name like:
/dkb500/smith/version1.1.4.3/testing_dat.dat
maps into:
/dkb500/smith/version1_1_4_3/testing_dat.dat
Multiple dots in directories are removed.
For example, a name like:
/dkb500/smith/version1.1.4.3/testing_dat.dat
maps into:
/dkb500/smith/version1143/testing_dat.dat
Multiple dots in the filename are turned into underscores, but the last dot is retained.
For example, a name like:
SDKDOC_1.4.0
maps into:
SDKDOC_1_4.0
Multiple dots in the filename are turned into underscores, but the first dot is retained.
For example, a name like:
SDKDOC_1.4.0
maps into:
SDKDOC_1.4_0
For filenames greater than 39 characters either to the left or the right of the single dot, that portion of the name is truncated on the right.
For example, a name like:
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.extension
maps into:
abcdefghijklmnopqrstuvwxyzabcdefghijklm.extension
Similarly, a name like:
somename.abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
maps into:
somename.abcdefghijklmnopqrstuvwxyzabcdefghijklm
For filenames that have more than 39 characters either to the left or to the right of the single dot in the filename, AND the total number of characters is less than [39+39 =] 78, the algorithm tries to shift the single dot so that there are no more than 39 characters to the left of the dot.
For example, a name like:
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz.extension
maps into:
abcdefghijklmnopqrstuvwxyzabcdefghijklm.nopqrstuvwxyzextension
There is support for representing a directory structure that is more than eight levels deep on an ODS-2 format disk.
If your application will use more than the OpenVMS maximum of eight nested directories, then define the following logicals to work around this restriction:
JAVA$DIRECTORY_MAPPING_COUNT nn: How many directory mappings exist?
JAVA$DIRECTORY_MAPPING_nn: Directory mapping value
where nn is an integer from 01 to 99.
For example, the following filename previously failed with SDK v 1.1.n for OpenVMS because the directory has too many levels for RMS:
/test1/test2/test3/test4/test5/test6/test7/test8/test9/test10
Using the directory mapping logic, you can redirect deep directory names to either a concealed logical or another directory.
Using the example above:
$ DEF JAVA$DIRECTORY_MAPPING_COUNT 1 !how many directory mappings.
$ DEF JAVA$DIRECTORY_MAPPING_01 -
_$ "/test1/test2/test3/test4/test5/test6/test7=/test7_relevel"
All files/directories created with a prefix of the following will
now be created in the directory /test7_relevel:
/test1/test2/test3/test4/test5/test6/test7
So, the filename:
/test1/test2/test3/test4/test5/test6/test7/test8/test9/test10/foo.bar
would actually be created as:
/test7_relevel/test8/test9/test10/foo.bar
Note: Define the JAVA$DIRECTORY_MAPPING_nn
logical only from the first character on. You cannot map directories
from the middle of a directory tree. Note the limit of 99 remappings.
Historically, at users' request, the JRE has performed filename mapping to map file names that are not directly representable on an OpenVMS file system into ones that are representable. This filename mapping requires several (potentially large) buffers on the stack. As the number of requested mappings increases, an increasingly larger number of such buffers are required. See Description of Mapping Options in UNIX-Style Filenames on OpenVMS Systems for a full discussion of these filename mappings.
The C RTL contains functionality that enriches the kinds of filenames you can directly specify on an ODS-5 volume under OpenVMS. If the files for your application are restricted to an ODS-5 volume, then you can probably reduce the number of filename mappings that you request.
Whenever you eliminate a filename mapping option, you reduce the
number of internal buffers that need to be allocated—leading
to a smaller memory footprint for your application. When no filename
mapping is needed (JAVA$FILENAME_CONTROLS defined to
0 or is undefined), you can lower the -ss (stack size)
value. The gains will be in memory usage and thread creation.
JAVA$CLASSPATHThe JAVA$CLASSPATH logical is an alternative way of
specifying the class path. Defining this logical overrides the CLASSPATH
logical, if set.
JAVA$CLASSPATH lets you define a class path using
OpenVMS file specification syntax. Therein lies its advantage: with
JAVA$CLASSPATH, you specify multiple paths with a comma-separated
expression; with CLASSPATH, you use a single, quoted
string comprised of colon-separated pathnames. JAVA$CLASSPATH,
therefore, avoids the OpenVMS 255-character length restriction that
you can encounter with CLASSPATH.
The following two sample statements accomplish the same result:
$ DEF JAVA$CLASSPATH USER1$:[SMITH.KIT]MY_CLASSES.ZIP,[]
$ DEF CLASSPATH "/user1$/smith/kit/my_classes.zip:."
Note that:
CLASSPATH is a colon-separated list enclosed in
quotes. JAVA$CLASSPATH is a comma-separated list not enclosed
in quotes. JAVA$CLASSPATH overrides CLASSPATH,
if JAVA$CLASSPATH is defined. -classpath option on a Java tool overrides
both JAVA$CLASSPATH and CLASSPATH. For further information, see Setting the Classpath on Sun's site.
JAVA$ENABLE_ENVIRONMENT_EXPANSIONYou can use the JAVA$ENABLE_ENVIRONMENT_EXPANSION
logical to bypass the DCL command-line character length limit:
$ define/job JAVA$ENABLE_ENVIRONMENT_EXPANSION TRUE
When this logical is defined, the JRE will attempt to expand any
logical or symbol that is preceded by "$"
on the Java command line. To bypass the DCL command-line character
length limit, you can define lengthy command-line operands as more
compact symbols or logical names and specify them on the Java command
line, each preceded by a "$". They will be
passed by DCL to the RTE for expansion. Also, if the logical is
a multi-valued logical, this feature will attempt to convert the
list into a UNIX list with a ":" as a delimiter.
For example:
$ define java$classpath [], dka200:[apache.jakarta.tomcat.lib]servlet.jar
$ extra_option = "-Dfoobar=value1 -Dfoobar1=value2"
$ java -cp $java$classpath $extra_option javaprogram
With the logical defined, the JRE would expand the command line to the following:
$ java -cp .:/dka200/apache/jakarta/tomcat/lib/servlet.jar -
" -Dfoobar=value1" "-Dfoobar1=value2" javaprogram
Note: This feature does not expand operands provided
via the "-V" method.
You can use the _JAVA_LAUNCHER_DEBUG
logical name as a diagnostic tool to see the arguments as they are
passed to the Java Virtual Machine.
There is a relaxation in the way shareable image names are used.
Before SDK v 1.1.8, the JNI example provided for OpenVMS systems
suggests you put your native code into a shareable image named JAVA$foo_SHR.EXE,
where you choose the foo portion of the image name. In
your Java code, you would have the following statement to load your
shareable image so you can call its native methods:
System.loadLibrary("foo");
This has the disadvantage of requiring users to create shareable
images using our reserved name prefix of JAVA$.
As of SDK v 1.1.8, you are allowed and encouraged to create shareable image names that do not collide with our namespace:
JAVA$. You
can avoid naming your images JAVA$foo_SHR
as long as you define a logical name JAVA$foo_SHR
to point to your image.
As a workaround to support old SDKs, we recommend you define
two logical names: "JAVA$foo_SHR" and
"foo", both pointing to your foo.exe
shareable image:
$ DEFINE/JOB JAVA$foo_SHR USER_DISK:[FOO]FOO.EXE
$ DEFINE/JOB foo USER_DISK:[FOO]FOO.EXE
The corresponding statement in your Java code would be:
System.loadLibrary("foo");
When you no longer support kits prior to SDK v 1.1.8, you could
stop defining the JAVA$foo_SHR logical.
The foo logical would then continue to
get you to your shareable image.
FOO.EXE,
then the call would be:
System.loadLibrary("foo");
.class files)
in the SYS$COMMON:[JAVA...] area. Instead, use the
CLASSPATH logical to make user classes known to the
environment. Future releases of the JDK could contain additional
images and/or .class files that might conflict with
user file names. (This is another good reason for you to use a
project prefix as suggested in the second item above.) The JDK kit provides examples, in SYS$COMMON:[JAVA$15x.VMS_DEMO],
that demonstrate step-by-step what is needed to write native C programs
to interact with Java code. Each example is in the form of a set
of files that contain sample Java and C code, which shows the basics
of how they interact, as well as command procedures that will compile,
link, and execute the sample JNI-based application. See the following
sections for more information on calling C code
from Java code, calling OpenVMS System
Services from Java code, and invoking
Java methods from C code.
The JDK kit provides file JNI_EXAMPLE.SAV that demonstrates
how to call C code from Java code. It also demonstrates how to handle
procedure names over 31 characters, also discussed in the Name-Shortening
Capability section.
There are two ways to shorten external names that are longer than 31 characters.
/NAMES=(AS_IS,SHORTENED)
qualifier. The SHORTENED keyword for this qualifier
instructs the compilers to shorten external names that are longer
than 31 characters. The RTE automatically shortens long names
using the same algorithm. This method is recommended, as it simplifies
the process of building native images, and can make debugging
easier, too. The file JNI_EXAMPLE.COM, in the JNI_EXAMPLE.SAV
save set, demonstrates this method.SHORTENED keyword
on the /NAMES qualifier, you can use the utility
program contained in the JNI_EXAMPLE.SAV save set.
This utility will manually shorten the long names in your native
code. The file JNI_EXAMPLE_31CHARS.COM
demonstrates this method.To obtain and use the example:
$ BACKUP SYS$COMMON:[JAVA$15x.VMS_DEMO]JNI_EXAMPLE.SAV/SAVE
[...]*.*
BACKUP:$ SET DEFAULT [.JNI]
JNI_README.TXT for an overview of what files
are in this package.JNI_EXAMPLE.COM or JNI_EXAMPLE_31CHARS.COM
to see how it all works. Note: You will first
need to update the procedure to reflect the version of the Java
environment you are running.The JDK kit provides file SYSTEM_SERVICE_INVOKE_DEMO.SAV
that demonstrates how to call OpenVMS System Services from Java
code. It is a complete example that compiles and links everything
it needs from the components in the demo kit file.
It creates two classes—LibGetJPI and LibGetSYI—which
act as jacket routines that call Java Native Interface (JNI) C-based
native code that actually accesses the GETJPI and GETSYI
system services.
This example demonstrates several techniques:
*DEF*.java files which
were hand-edited from their corresponding *DEF*.h
files for these system services.SCAN_GLOBALS_FOR_OPTION.COM and JAVA$BUILD_OPTION.EXE
to dynamically create the .OPT files needed for linking
the shareable libraries.To obtain and use the example:
$ BACKUP -
SYS$COMMON:[JAVA$15x.VMS_DEMO]SYSTEM_SERVICE_INVOKE_DEMO.SAV/SAVE
[...]*.*
BACKUP:$ SET DEFAULT [.SYSTEM_SERVICE_INVOKE_DEMO]
$ @SYS$COMMON:[JAVA$15x.COM]JAVA$15x_SETUP.COM
$ @BUILD_EXAMPLE.COMThe JDK kit provides file INVOKE_JAVA_FROM_C_EXAMPLE.SAV
that demonstrates how to write an application that starts in C code
and then calls Java methods.
The example program demonstrates:
SCAN_GLOBALS_FOR_OPTION.COM and JAVA$BUILD_OPTION.EXE
to dynamically create the .OPT files needed for linking
the shareable libraries.To obtain and use the example:
$ BACKUP -
SYS$COMMON:[JAVA$15x.VMS_DEMO]INVOKE_JAVA_FROM_C_EXAMPLE.SAV/SAVE
[...]*.*
BACKUP:$ SET DEFAULT [.INVOKE_JAVA_FROM_C]
$ @SYS$COMMON:[JAVA$15x.COM]JAVA$15x_SETUP.COM
$ @JNIINVTEST.COMFor information on handling procedure names longer than 31 characters, see the Name-Shortening Capability section.
The JRE for OpenVMS can shorten long procedure names (more than
31 characters) using the same translation algorithm used by the
C/C++ compilers from HP. To use this feature, compile your C/C++
code with the /NAMES=(AS_IS,SHORTENED) qualifier.
The old name-shortening method using SCAN_FOR_31_CHARS.COM
is still supported; you can choose either method. (For information
on using SCAN_FOR_31_CHARS.COM, included in the JNI_EXAMPLE.SAV
save set, follow the instructions in the Calling
C Code from Java Code section, and then read the files JNI_README.TXT,
JNI_EXAMPLE.COM, and SCAN_FOR_31_CHARS.COM.
You can run SCAN_FOR_31_CHARS.COM manually to produce
.H files that redefine the oversized name to be 31
characters.) The names produced in this way are different from those
produced by the C/C++ compilers.
When the JRE is confronted with an oversized name, it first tries
to find a match using the new compiler-based name compression algorithm
— the same one used by running the C or C++ compiler with
the /NAMES=(AS_IS,SHORTENED) qualifier.
If the JRE fails to find such a match, it then tries to create
a short name using the algorithm used by SCAN_FOR_31_CHARS.COM.
Although the old manual name-shortening method will continue to work, we encourage you to take advantage of the new, more automatic method.
The JRE supports limited file-sharing and has several user-selectable
modes of file sharing. To enable JRE file-sharing modes, define
the logical JAVA$FILE_OPEN_MODE to any of the following
values: