These release notes describe the final release of the Java Development Kit (JDK) Version 1.1.6 for OpenVMS Alpha. This JDK Version 1.1.6 is an update of the July 13th JDK 1.1.6 beta2 release and represents the Final JDK Version 1.1.6 for OpenVMS Alpha. This kit can be used to develop and run Java applets and programs on OpenVMS for Alpha Versions 7.1 and higher.
Prerequisites
One Product, Two Faces
Jit Compiler Usage
UNIX Style Filenames on OpenVMS Systems
Stream_LF File Format Required
Setting JAVA$CLASSPATH
Command Qualifiers
Java Commands on OpenVMS Systems
Running a Java Multimedia Applet
Fixed Problems and Other Changes
Known Issues
Prerequisites for installing this kit include:
The following ECOs must be installed for this JDK to function correctly. These ECO (patch) files can be accessed at http://search.service.digital.com/
At that URL, enter a search on the full ECO name shown in the table below. Each ECO has its own cover letter or README file describing the installation.
ECO Name Comment/Fix Description ALPACRT06_071 DECC fixes -- fork, exec ALPBASE02_071 Fixes needed to enable ALPACRT06_071 ALPDCL01_071 Fixes for multiple kernal threading problem ALPSYSA01_071 Higher-priority thread blocking ALPSYSB02_071 IEEE arithmetic ALPTHREADS_03071 Kernel threads fixes
The above list of ECOs was current when this release note was written. Because the status of ECOs changes frequently as new versions supersede previous versions, we recommend that you query the ECO cited above, and install the latest version shown by your query. To verify that you have the correct file, refer to the ECO Note found on the page of the ECO you queried. Generally, this Note lists any ECO kits superseded by the most current kit.
This kit includes all the functionality and bug fixes that are in Sun Microsystems JDK 1.1.6.
If you identify any problems, please use the accompanying problem-report template (bugreport.txt) to send a bug report to java-bugs@zko.dec.com, specifying the following information:
Send comments or suggestions on the JDK to java-info@zko.dec.com.
In addition to preserving the UNIX style JDK command-line interface, this JDK product also lets you use it as if it were a traditional OpenVMS product.
This dual interface is achieved with the following file installed during the product installation:
SYS$MANAGER:JAVA$SETUP.COM
To use a DCL interface:
$ DEFINE JAVA$USE_DCL 1
$ @SYS$MANAGER:JAVA$SETUP
To use a UNIX style command-line interface:
$ DEASSIGN JAVA$USE_DCL
$ @SYS$MANAGER:JAVA$SETUP
These commands could be added to SYS$MANAGER:SYLOGIN.COM or entered into your local or project-wide login.com file.
See the section 'Setting JAVA$CLASSPATH' in these release notes for details about the behavior if both CLASSPATH and JAVA$CLASSPATH are defined.
This release of the JDK contains a Just-in-Time (JIT) compiler to substantially increase run-time performance. The JIT compiler provides on-the-fly compilation of your application's Java byte-codes and runtime calls into native Alpha machine code. This results in significantly faster execution of your Java application compared with running it using the Java interpreter, while maintaining the same behavior.
Whether jit compiler will or will not be used is controlled by the -jit switch:
There are a number of issues trying to represent UNIX directory and file specifications on an OpenVMS Alpha system.
If you try to run a Java application developed elsewhere on an OpenVMS Alpha system, you might encounter problems with file and directory names.
Java on OpenVMS Alpha systems can use a number of mapping algorithms that try to make a UNIX-style name usable under an OpenVMS Alpha 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$SYSROOT:[SYSHLP.JAVA]JAVA$FILENAME_CONTROLS.COM
This file is called by SYS$MANAGER:JAVA$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 Table
Option name Value
Support UNIX and VMS 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 %x40000000
To see individual filename mappings as they occur, you can 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.
Use this to map a mix of UNIX and VMS filenames into UNIX-style names.
For example,
this: $disk1:[smith]/test.jtjtj/test.jtjtj
maps into this: /$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. DECC 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
A name like:
/dkb500/smith/version1.1.4.3/testing_dat.dat
Maps into:
/dkb500/smith/version1_1_4_3/testing_dat.dat
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: JDKDOC_1.1.6
maps into: JDKDOC_1_1.6
Multiple dots in the filename are turned into underscores, but the FIRST dot is retained:
For example:
A name like: JDKDOC_1.1.6
maps into: JDKDOC_1.1_6
For filenames greater than 39 characters either to the left of the single dot 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 8 levels deep.
If your application will use more than the OpenVMS maximum of 8 nested directories, then define the following logicals to work around this restriction:
JAVA$DIRECTORY_MAPPING_COUNT nn : How many directory mapping exist?
JAVA$DIRECTORY_MAPPING_nn : Directory mapping value
where nn is an integer from 01 to 99.
For example, the following filename previous failed with JDK V1.1 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 following filename would actually be created as
/test7_relevel/test8/test9/test10/foo.bar:
/test1/test2/test3/test4/test5/test6/test7/test8/test9/test10/foo.bar
Note: Define the JAVA$DIRECTORY_MAPPING_nn logical only from the first character on. It will not match directories in the middle of the filename. Note the limit of 99 remappings.
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.
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.
To get a file into Stream_LF record format, do the following:
$ CONVERT/FDL=SYS$COMMON:[SYSHLP.JAVA]STREAM_LF.FDL input_filename -
output_filename
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 (STMLF), 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 STMLF 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
The JAVA$CLASSPATH logical lets you define a classpath using OpenVMS filespecs.
Defining this logical overrides the CLASSPATH logical, if set.
The following two sample statements accomplish the same result:
$ DEF JAVA$CLASSPATH USER1$:[SMITH.KIT]JDK116_CLASSES.ZIP,[] $ DEF CLASSPATH "/user1$/smith/kit/jdk116_class.zip:."
Note that:
You can specify the options on java commands as either OpenVMS DCL style qualifiers or DIGITAL UNIX style switches.
In the current implementation of the /PARAMETER qualfier, the operand of the qualfier is used internally like a -J switch.
Therefore, if you write the following:
$ javac /PARAMETER="-mx16m" "sanitytest.java"
Internally, java is invoked as if you had written:
$ javac -mx16m "sun.tools.javac.Main" "sanitytest.java"
However, if you need to pass multiple arguments using the /PARAMETER qualfier, you can write:
/PARAMETER=("-mx16m","-ms16m") "sanitytest.java"
This is treated internally as :
javac -mx16m -ms16m sun.tools.javac.Main "sanitytest.java"
In general, (though there may be exceptions) wherever the UNIX-style command line takes a space-separated list, the DCL-style interface takes a comma-separated list.
An example involving a set of arguments:
To run a program called Test and pass it arguments 27, 28 and 29:
$ JAVA "Test" 27 28 29
becomes
$ JAVA "Test",27,28,29
Similarly,
$ JAR -cf0 multiple.jar "SanityTest.java" "ShowDate.java"
becomes
$ JAR /NEW /NOCOMPRESS /JAR=multiple.jar "SanityTest.java","ShowDate.java"
And for a set of repeated switches:
$ javac -J-mx32m -J-ms32m -deprecated "SanityTest.java"
becomes
$ javac /PARAM=("-mx32m","-ms32m") /DEPRECATED "SanityTest.java"
java [basic runtime-interpreter]
javac [Compiler]
appletviewer [Appletviewer]
javap [Class file disassembler]
javah [Header and Stub file Generator]
javadoc [Documentation Generator]
jar [Java Archiver]
serialver [The Serial Version Command]
native2ascii [Native-to-ASCII Converter]
jdb [java debugger]
rmic [Stub and skeleton class file generator for Java
objects implementing the java.rmi.Remote interface.]
rmiregistry [Remote object registry ]
javakey [Java Key Management and Digital Signatures]
In order to successfully use an application that uses audio, four things must be in place:
These are things to check and error messages you might see when running a Java multimedia applet on an OpenVMS Alpha system:
$SHOW DEV AU
Device Device Error
Name Status Count
AUA0: Online 0
$ appletviewer "http://andice.alf.dec.com/bouncing_heads/demo.html"
audio device busy (attempt 1 out of 5)
audio device busy (attempt 2 out of 5)
audio device busy (attempt 3 out of 5)
audio device busy (attempt 4 out of 5)
audio device busy (attempt 5 out of 5)
audio player exit
$ appletviewer "http://andice.alf.dec.com/bouncing_heads/demo.html"
%IPCT-F-ERROR, open association failure
%SYSTEM-?-NOSYSNAM, operation requires SYSNAM privilege
$ DEFINE JAVA$ENABLE_MMEDIA TRUE
For example:
$ appletviewer "http://andice.alf.dec.com/bouncing_heads/demo.html"
Multimedia server not running
$ @SYS$STARTUP:MMOV$STARTUP
You need CMKRNL, WORLD, DETACH, SYSNAM, and BYPASS privilege to run
the server.
%SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
$ SET PROCESS/PRIV=(CMKRNL, WORLD, DETACH, SYSNAM, BYPASS)
$ @SYS$STARTUP:MMOV$STARTUP
%RUN-S-PROC_ID, identification of created process is xxxxxxxx
The following changes and fixes have been made with the JDK V1.1.6 final kit for OpenVMS Alpha:
In prior releases, when you used the DCL-style interface, java displayed the arguments of the fabricated UNIX-style command line.
In this release this feature is turned off by default. To get back to the former behavior, you can define the logical JAVA$SHOW_MAPPED_DCL_ARGS.
For example:
$ deassign JAVA$SHOW_MAPPED_DCL_ARGS
$ javac /DEBUG /PARAM=("-mx32m","-ms32m") "SanityTest.java"
$
$ define JAVA$SHOW_MAPPED_DCL_ARGS 1
$ javac /DEBUG /PARAM=("-mx32m","-ms32m") "SanityTest.java"
0: javac
1: -mx32m
2: -ms32m
3: sun.tools.javac.Main
4: -g
5: SanityTest.java
The problem was:
If a very small double value (e.g. 2.22507e-308) was cast to float, it turned into an apparently random float value, rather than zero.
Casting a large double value (e.g. 1.79769e+308) to float should yield infinity, but it did not.
In JDK V1.1.5, if an error occurred while creating a child, the JDK would exit without any error message. With JDK V1.1.6, the JDK throws an exception with a VMS error status.
With JDK V1.1.6, Japanese locales are correctly supported.
Note: Because DCL sometimes converts character case, it is recommended that you quote all locale strings on the command line. For example, consider the following:
$ javac -encoding EUCJIS japan.java
Javac will not honor the EUCJIS encoding in the above command because DCL could convert EUCJIS to eucjis. The correct syntax should be:
$ javac -encoding "EUCJIS" japan.java
JDK V1.1.6 contains enhancements to font_properties.ja to better support the fonts available with Japanese Motif.
Isolated instances of file-parsing problems were corrected, and Directory Remapping capability was added.
The JDK has several user-selectable modes of file sharing To enable JDK file-sharing modes, define the logical JAVA$FILE_OPEN_MODE to any of the following values:
0 or not defined pre V1.1.6 file sharing (none)
2 sync writes, every write to a file,
the file is sync with the disk.
NOTE: A sync for every write, gives you file sharing
close to what the JDK expects. However, things that
normally took seconds to run, can take minutes or longer.
3 A table of all open file descriptors is kept
by the JDK. The JDK then monitors when an
application writes to a file, and sets a
write_pending flag. Before every read operation
the JDK scans the list of open file descriptors.
If a match is found with a write pending, the
pending write is flushed to the disk before the read.
Limitations: only one process can share the file reliably.
We are working with DEC C engineering to enhance the file-sharing features in the DEC C RTL and the JDK.
On OpenVMS Alpha, Java process creation and parent-child relationships are managed by native threads. If they pass data between them it is done by mailboxes. For example, a typical scenario is where a child thread produces a stream of output and the parent thread consumes this stream as input.
Schematically,
Child Writes --> Mailbox --> Parent Reads
Some applications are written such that the parent starts off the child and then waits for the child to finish before starting to read its stream of data. In others applications, the parent starts reading as soon as it can, but cannot keep up with the child. Both of these approaches can get into trouble.
The trouble arises because the mailboxes are of a finite size.
If the mailbox fills up, the child is blocked from doing further work and never gets done. Meanwhile the parent is waiting for the child to finish, and also cannot proceed. This state is known as a Read-Write MailBoX (RWMBX) wait state (or RWINS) and the process running this application is blocked.
To try to avoid this situation, Java on OpenVMS Alpha does buffering between the mailbox and the consumer. One thread reads data from the mailbox and stores it in heap storage. Another thread reads buffered data from this heap and delivers it to the parent when it asks for it.
Schematically,
Child Writes --> Mailbox --> PutToHeap -->GetFrom Heap -->Parent Reads
In the case where the parent is waiting for the child to finish, this buffering may empty the mailbox enough so that the child can continue to run and finishes, thereby freeing the parent to continue as well. In the case where the parent is continually reading but is temporarily being overwhelmed, the buffering smooths the production-consumption data flow.
If the parent is really waiting for the child to complete before consuming any of the information stream, this buffering mechanism itself starts to fail when the volume of output exceeds the amount of heap storage available. When no more heap is available, PutToHeap cannot empty the Mailbox, and again you face (RWMBX or RWINS) wait state. The blocked state persists unless some asynchronous agent comes along and changes the resources involved -- for example, releases some heap storage.
In most cases, however, the added capacity of heap storage is enough for the child to complete and the parent to continue.
As a further enhancement to control this data flow, we monitor the pipeline for how many messages are outstanding.
Schematically,
Child Writes --> Mailbox --> PutToHeap -->GetFrom Heap -->Parent Reads
^ ^
| |
+----- count messages outstanding --------+
When the number of messages written exceeds the number read by an amount equal to the lesser of 1024 and the value of the logical JAVA$FORK_MAILBOX_MESSAGES, then we stop the writes to prevent the RWMBX condition. JAVA$FORK_MAILBOX_MESSAGES is assumed to be 8 if not defined.
This temporary curtailment of production allows the parent thread to catch up (get within the exceeded message threshold) and the overall application continues.
As mentioned above, if JAVA$FORK_MAILBOX_MESSAGES is not defined it is assumed to be 8. With this value in control, any time the writer gets 8 records ahead of the consumer, the writer is temporarily suspended. For applications that produce many small records, you may want to set a value of JAVA$FORK_MAILBOX_MESSAGES to a larger value -- something on the order of 1024 divided by your typical mailbox recordsize. The bigger you can make it -- think of it as a blocking factor -- the more efficient the operation become because you are minimizing the start-stop time of the producer thread. If you make it too large you may induce the RWMBX state. If you see the Java application in RWMBX state for a period of time without having explicitly used JAVA$FORK_MAILBOX_MESSAGES, you should try setting to a value less than it default value of 8.
This new scheme, whereby the mailbox traffic is buffered, is a new feature for release Java JDK 1.1.6. If this feature causes you problems you can revert to unbuffered behavior for exec and pipes (as it was in releases JDK v1.1-beta to v1.1.5-beta3) by defining the logical JAVA$EXEC_USE_PIPES.
$ DEFINE JAVA$EXEC_USE_PIPES 1 ! use unbuffered behavior
The following are known issues with the JDK V1.1.6 final kit for OpenVMS Alpha:
Command lines on OpenVMS Alpha cannot exceed 255 characters. This means you cannot build command lines like the following:
$ java "sun.tools.javac.Main" -
"MyClass001.java" -
"MyClass002.java" -
"MyClass003.java" -
...
"MyClass127.java" -
"MyClass128.java" -
To circumvent this shortcoming, a -V switch has been implemented that allows you to put command operands in another file and simply name that operand file on the -V switch.
For example, you can write the following:
$ java "sun.tools.javac.Main" "-V" CLASS_LIST_FILE.DAT
where CLASS_LIST_FILE.DAT contains:
MyClass001.java
MyClass002.java
MyClass003.java
...
MyClass127.java
MyClass128.java
More typical usage is:
$ java "sun.tools.javac.Main" "-V" sys$input:
MyClass001.java
MyClass002.java
MyClass003.java
...
MyClass127.java
MyClass128.java
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.
Although included in the kit, the JIT has not been tuned/optimized. Register allocation, branch prediction, and so on are not finalized.
Currently there is no way to distinquish filenames that differ only
in case. For example: Temp.dat vs. temp.dat
OpenVMS systems do not have a dlopen, dlsym, and/or dlclose runtime routine. To be able to support dynamically loaded runtime libraries, we have created dlopen, dlsym, and dlclose routines using LIB$FIND_IMAGE_SYMBOL (FIS).
FIS does not support pure dynamically linked library in the same manner as dlopen does. FIS does NOT resolve global symbols from other shareable libraries at runtime. Under OpenVMS, this must be done at link time, and not at run time.
Example:
The Java Zip RTL library needs java_lang_String_intern, which is declared in the Main Java library(JAVA.SO). Under UNIX, dlopen resolves this external global at runtime.
Under OpenVMS, because FIS does NOT resolve any external globals at runtime that were not found at link time, the Java Zip library must be linked against the main Java library to allow java_lang_String_intern to be found at runtime.
On systems other than OpenVMS, when the JDK needs to find class definitions, it consults the environment variable CLASSPATH. In addition to the paths found through CLASSPATH, the JDK automatically appends the location of the system classes. For example, default paths:
.:$JAVA/classes:$JAVA/lib/classes.zip UNIX systems
.;$JAVA\classes;$JAVA\lib\classes.zip Windows systems
For OpenVMS systems, there is no 'location of the system classes' currently implemented. You should have '/sys$common/java/lib/jdk116_classes.zip' explicitly on your classpath, as a minimum.
Note that a file named ".;" will make classpath fail.
Using a classpath that contains a "." on the path will fail if there is a file without a name or extension (that is ".;").
Example:
$show log classpath
"CLASSPATH" =".:/dkb500/jck-11a/jck-11a_classes.zip:/dkb500/changed_java_fil
es/classes:/sys$sysroot/java/jdk116_classes.zip" (LNM$PROCESS_TABLE)
$ java "Helloworld"
hello World, java on VMS
hello World, java on VMS
$ create .;
Exit
$ java "Helloworld"
Can't find class Helloworld
$del .;
If you have the situation where position on the command line is significant, you can't replicate it in DCL using straightforward CLI calls.
For example, assume the following two DIGITAL UNIX commands are interpreted differently:
command -x something rest_of_line command something -x rest_of_line
Then, using DCL, you cannot simply write:
command /X something rest_of_line
And expect it to behave differently from:
command something /X rest_of_line
At runtime, you can only determine that the /X qualifier was or was not present. You cannot tell where on the command line it occurred [without extra work, if at all].
Using UNIX-style command-line switches, you can repeat some switches with the effect of concatenating the individual results.
For example, you can write:
$ java -classpath "/sys$library/java/jdk116_classes.zip" -
-classpath "/user1$/test/test3classes/"
and the net effect is as if you wrote:
$ java -
-classpath "/sys$library/java/jdk116_classes.zip:/user1$/test/test3classes/"
You cannot accomplish the same thing with the DCL /CLASSPATH qualifier.
For example, if you write the following:
$ java /CLASSPATH="/sys$library/java/jdk116_classes.zip" -
/CLASSPATH="/user1$/test/test3classes/"
only the last qualifier
(/CLASSPATH="/user1$/test/test3classes/") is seen.
If you want both, you need to specify both in a single /CLASSPATH qualfier:
$ java /CLASSPATH="/sys$library/java/jdk116_classes.zip:/user1$/test/test3classes/"
You may see the following message when trying to display to a VAXstation:
X error event received from server: BadValue (integer parameter out of
range for operation)
Major opcode of failed request: 61 (X_ClearArea)
Value in failed request: 0xffff****
Serial number of failed request: ###
Current serial number in output stream: ###
%XLIB-E-ERROREVENT, error event received from server
%TRACE-E-TRACEBACK, symbolic stack dump follows
(* indicates a variance in the occurrence of the width & height)
This is a problem with (width, height).
The OpenVMS server implements these parameters (width, height) as a signed word as opposed to CARD16(unsigned word) as specified by the X Windows System Protocol. Hence, anything over 32767, (hex 7fff) is unacceptable to an OpenVMS server.
To fix this, in file SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM, specify:
$DEFINE/TABLE=DECW$SERVER0_TABLE DECW$CARD16_VALIDATE TRUE
A small number of Java utilities (javap, javah, and verify), do not exit cleanly if they are aborted with a ^Y.
When you then type another command, or even $ EXIT, you might find that you have to do a second ^Y and another $ EXIT in order to stop all the threads that are running on your behalf.
If the application is deadlocked, holding a resource required by one of the exit handler's routines, the application will continue to hang, even after type Ctrl/Y and exit. In these cases, type a second Ctrl/Y and STOP to terminate the application without running exit handlers. This behavior is not unique to Java applications but is characteristic of DECThreads operating in a multi-threaded environment. See DECThread Manual (Chapter B) for a fuller discussion of this issue.
On OpenVMS systems, you may occasionally experience OutOfMemory errors in applications that do not require extra memory on other Java platforms.
The memory allocation routines used in the JDK on OpenVMS systems are somewhat different than those found on other platforms such as DIGITAL UNIX.
On OpenVMS sytems, malloc is used instead of mmap. This means that the JAVA heap is a fixed size. The default maximum heap size is 32m by default for most Unix systems. Requiring OpenVMS customers to allocate 32mb for each Java application seems severe. So, the default maximum heap size on OpenVMS systems is 6mb, and it does not grow beyond this.
You can override the maximum memory heap size from the command line using -mx32m. This would give you the same maximum heap size found on most UNIX systems. Keep in mind that 32m is at least 65,536 pages of virtual memory for just the heap.
Also consider that the amount of memory consumed grows with the complexity of the classpath you specify. Try to keep your classpath restricted to only those files and directories that are actually needed for your application.
As currently implemented, the code that pre-processes the DCL command line for Java and its utilities uses a fixed buffer of 1000 entries for command-line operands. This exceeds what you can express on a single DCL command line (255 characters).
However, you can reach this limit if you are using the /COMMAND_LINE qualifier to point to a file containing close to 1000 directory names or filenames.
When using Japanese Motif, you should use the following font specification sizes 8, 10, 12, 14, 18, or 24. When other sizes are specified by an application, Japanese text is not displayed. For Japanese Motif, Java font specifications for application and applets are describe in the file sys$common:[java.lib]FONT_PROPERTIES.JA.
^\ to get a printout of the Java stack.
On OpenVMS Alpha systems, the operation of sockets is controlled by Event Flag Numbers (EFNs). The more sockets you operate simultaneously, the more EFNs you consume. There are only 32 EFNs available for your use. If you start to exhaust the number of available EFNs, you will see an error message like the following:
Thu May 28 17:44:22 EDT 1998] Error starting connection.
java.net.SocketException: insufficient event flags
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:387)
at java.net.ServerSocket.implAccept(ServerSocket.java:206)
...
The only workaround is to restrict the number of simultaneous sockets that the application is using.