The Minimum You Need to Know

About Java on OpenVMS
Volume 1

By Roland Hughes

Logikal Solutions

Copyright © 2005 by Roland Hughes
All rights reserved

ISBN 0-9770866-1-5
This book was published by Logikal Solutions for the author. Neither Logikal Solutions
nor the author shall be held responsible for any dam age, claim , or expense incurred by a
user of this book and its accom panying CD-ROM as a result of its use or reliance upon the
contents contained in either the book or the CD-ROM .

These trademarks belong to the following companies:
CDD
Oracle Corporation
CMS
Hewlett Packard Corporation
DEC
Digital Equipment Corporation
DEC BASIC
Hewlett Packard Corporation
DEC COBOL
Hewlett Packard Corporation
DEC C
Hewlett Packard Corporation
DECSET
Hewlett Packard Corporation
FMS
Hewlett Packard Corporation
HP
Hewlett Packard Corporation
IBM
International Business Machines, Inc.
LSE
Hewlett Packard Corporation
OpenVMS
Hewlett Packard Corporation
ORACLE
Oracle Corporation
Purify
Pure Software, Inc.
RMS
Hewlett Packard Corporation
RDB
Oracle Corporation
Windows
Microsoft Corporation
WordPerfect
Correl Corporation
UNIX
The Open Group
All other trademarks inadvertently missing from this list are trademarks of their respective owners. A best
effort was made to appropriately capitalize all trademarks which were known at the time of this writing.
Neither the publisher nor the author can attest to the accuracy of this information. Use of a term in this book
should not be regarded as affecting the validity of any trademark or service mark.

Acknowledgments
I would like to dedicate this book to you, the reader. You have chosen to work with
the greatest operating system ever created even if it is no longer in vogue. You have
endured the dem eaning salaries and attitudes presented to you by w hat passes for
m anagem ent these days. You have stayed in the trenches and fought the good fight.
There is one person I would like to honor at this point. Not because he has anything
at all to do with the subject matter, but he, like OpenVM S, m anaged to touch an awful lot
of lives during his brief stay on this planet. That person would be M r. Peter Jennings.
W e never met in this life, yet his voice found its w ay in on m any an evening. Whenever
tragedy struck som ewhere in the world it w as his newscast I found m yself turning to, for
not just the story, but the story behind the story. Som e tim es you learned m ore from the
side show spot than the actual newscast put on by other networks. In many ways I find
m yself identifying O penVM S with those sam e broadcasts. It is the OS behind the big
accomplishm ent. The story behind the story.

Source Code License
Any person owning a copy of this book m ay use the source code from this book and
accom panying CD-ROM freely w hen developing software for their personal use, their
companies use, or their client’s use. Such persons may include the source code either
m odified or unm odified provided that the source delivered makes reference to the original
author and is delivered as part of a fully functional application. It is expressly forbidden
for anyone to post this software on any bulletin board system , internet W eb site, or other
electronic distribution m edium without the express written consent of the author. It is
also expressly forbidden to sell this source as part of a library or shareware distribution
of source.
U sers of the source code contained within this book and on the accom panying CDROM agree to hold harm less both the author and the publisher for any errors, om issions,
losses, or other financial consequences w hich result from the use of said source. This
software is provided “as is” with no warranty of any kind expressed or im plied.

Table of Contents
Introduction.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.1 Why Java?.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.2 Approach of This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.3 Prerequisites for This Book. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.4 Obtaining and Installing Java.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I.5 Major Pitfalls of Java on OpenVMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I-1
I-1
I-3
I-4
I-4
I-7

Chapter 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Basics of Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1 A Little Bit of History and Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.2 Data Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
1.3 Everything is a Class (almost). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
1.4 Reference not Pointer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
1.5 The Sandbox.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
1.6 Garbage Collection.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
1.7 No Include Files or Preprocessor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
1.8 Constructors and Finalizers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
1.9 Arithmetic Operators.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
1.10 Relational Operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
1.11 Boolean Operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
1.12 Bitwise Operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
1.13 Assignment Operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
1.14 Comments.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13
1.15 Abstract Classes and Methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
1.16 Inheritance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
1.17 Polymorphism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
1.18 Source Code Organization and Style. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
1.19 Modifiers for Data Types and Methods.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
1.20 Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
1.21 Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
1.22 Threads.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23
1.23 Exceptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-26
1.24 JAVA$CLASSPATH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
1.25 A Little Lecture on Strings and References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28
1.26 Java Follow Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30
1.27 Exercises.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32
Chapter 2
Using RTL and SYS Calls.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.1 Goal of This Chapter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.2 Order of Development with JNI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.3 Creating Linker Option Files for JNI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.4 LibGetLogical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
2.5 Programming Assignment 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18
2.6 VMSLogical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19
2.7 Programming Assignment 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
2.8 VMSDate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
2.9 Programming Assignment 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
2.10 VMSSpawn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40
2.11 Programming Assignment 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44

2.12 Words of Warning About LIB$SPAWN(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-44
2.13 RTL and SYS Followup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-45
2.14 Exercises.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-46
Chapter 3
Accessing RMS Indexed Files.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.1 The Choices We Make. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.2 Building What We Need. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
3.3 The Native Interface Code.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29
3.4 One More Indexed File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48
3.5 RMS Followup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-50
3.6 Programming Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
3.7 Exercises.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51
Chapter 4
Interfacing With FMS.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.1 Why Use FMS?.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
4.2 Our Fms Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2
4.3 FMS Follow Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-20
Chapter 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Building Java Via MMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.1 The philosophy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
5.2 Logical Name Table Modifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.3 Build Command File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
5.4 The Infrastructure MMS Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-6
5.5 Running Our New Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-18
5.6 Programming Assignment.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-19
5.7 Exercises.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-20
Chapter 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Mega Zillionare Application - RMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.1 What to Expect.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.2 String Dates in Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6.3 Importing Data.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
6.4 Bulk Reporting Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
6.5 Creating Our Stats File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
6.6 Programming Assignment 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
6.7 The Most Report.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
6.7 Programming Assignment 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
6.8 The Due Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
6.9 Programming Assignment 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
6.10 The Browse Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
6.12 The Entry Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-32
6.13 The Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-38
6.14 Programming Assignment 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-42
Chapter 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
Using the Buffers Directly - RMS2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.1 The Intention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.2 How Hurt Are You?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
7.3 Programming Assignment One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.4 Upgrade Before Continuing.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-2
7.5 Our New Java Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
7.6 Programming Assignment Two.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-14

7.7 The Support and Open Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.8 Reading Records.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.9 Programming Assignment Three. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.10 Updates and Deletes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.11 Programming Assignment Four. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.12 Writing a Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.13 Follow Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7-14
7-20
7-25
7-26
7-27
7-27
7-28

Chapter 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
RDB Via JDBC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
8.1 Setting Things Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1
8.2 A Sample Java Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
8.3 Programming Assignment One. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
8.4 Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
8.5 Some Serious Flaws. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
8.6 Our Main Program.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
8.7 Our Prompt Routine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-18
8.8 The Import Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
8.9 Stats Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
8.10 The Due Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
8.11 The Dump Report.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-29
8.12 Our Browse Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
8.13 Programming Assignment Two.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
8.14 The Maintenance Module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
8.15 Programming Assignment Three. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47
8.16 Programming Assignment Four. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47
8.17 RDB Follow Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
8.18 JAR Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
8.19 Java Follow Up. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
Chapter 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
Ruminations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1
9.1 Vendor Management Systems and the End of Consulting Firms. . . . . . . . . . . . . . . . . . 9-1
9.2 The Tech Farm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4
9.3 Return of the 30 Year System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
9.4 Do You Really Want to Work in IT?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-13
9.5 Solve the Whole Problem.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
9.6 The Mythical Business Analyst.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
9.7 The Much Maligned LF/CR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-29
Answers to Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-32

Page left blank intentionally.

Introduction
I.1 W hy Java?
That’s a very good question. It’s a question I’ve asked m yself every tim e I’ve had to
touch the language. If you grew up during the days of the languages we covered in the
first book of this set, it is a question you will ask yourself over and over again. There is
no good answer — none what-so-ever.
Considering I’m about to w rite an entire book on areas of the language not norm ally
covered, that opening paragraph probably shocks you. Sadly, it’s the truth. W hat is even
m ore sad is that m anagem ent m akes its decisions based upon four-color glossies, and
there are a lot of four-color glossies for Java products these days. The honest answ er is
“Because of the four-color glossies”.
W hat inevitably happens in this m arket is m anagem ent keeps trying to find “cheaper
resources”. This leads them to fish lower and lower in the skill pond. Many of you reading
this are working in mainfram e or m idrange shops with an awful lot of PC hackers floating
around. If you were paying attention, you watched it happen.
It started with som eone from Mahogany Row reading a bathroom length article in the
weekly trade press. There it spouted that if you weren’t on the W eb you wouldn’t be in
business for long. These articles all occurred prior to the Dot-Com flam e out, which lead
to the nicknam e DOT-BOM B.
A rash of static W eb pages w ent up. These were follow ed by the ability to actually
send em ail. Along the way, som ebody said “Hey! W ouldn’t it be nice if custom ers could
actually place orders using this?” Coding up those kind of W eb pages by hand was a lot
of work. The skill and IQ level of college students had been “dum bed dow n” to the level
of Visual Basic and other “visual” products. None of the current crop of “visual” tools
worked well on the W eb, but never fear, a rash of “visual” type tools using Java soon
appeared. This allowed what is currently passing for college graduates to becom e
em ployed creating W eb sites and since they were recent graduates, they were cheaper
than skilled professionals.
Once the Dot-Com flam e out happened, Mahogany Row sat back and sm iled. They
were able to pick up a lot of W eb and Java program m ers for less m oney than they paid the
box stackers in the warehouse. A m ass proliferation of little W eb applications sprang up
all around your com pany. The wheel was re-invented at least a dozen tim es per quarter.
Graphics got added to W eb pages until the internal network was slow pulling the pages
up. Nobody even thought about the poor Schm oe dialed in with a 14.4 modem , or worse,
a 56K m odem that only got a 14.4 connection from their ISP. You couldn’t even walk in
the m achine room because everybody working on W eb pages had to have their own server.
Right around that tim e is when som eone said “Hey! W ouldn’t it be nice if custom ers could
actually place orders using this?”

I-2

Introduction

So, another rash of Java oriented comm ercial products hit the m arket. This tim e they
were “m iddleware”. Every vendor was hawking them and hawking N-tier system s design.
At about this point, alert readers began to realize that Java is some of the most expensive
“freeware” they could ever work with.
W hen you com e up through the ranks working on OpenVM S, you cannot begin to
understand w hy anyone wants an N-tier design. You’ve always had a cluster to work
with. You’ve designed system s to use ACM S servers on every node in the cluster,
consequently, you’ve never had to deal with load balancing because QTI did it for you.
You’ve used RDB for your database because it was cluster aware. With DTM wrapping
your transactions in its protective cloak, you’ve never had to w orry about transaction
recovery because all transactions were guaranteed to com plete. W ith nodes of your cluster
scattered across m ultiple states, you never even had to worry about fail over. As long as
at least one node stayed up you w ere golden. Yes, the node would be gasping for breath
being run so hard, but it w ould run. Let m e put it to you in terms that will make sense:
N-tier is what you do when you don’t have a good platform to work with.
The concept of N-tier is pretty m uch “The Swarm Principle”. If you m ass together
enough of an inferior force, you can overrun a superior force. Anyone who has ever
watched TV has probably seen at least one com m ercial or m ovie where som e hapless
Schm oe is being attacked by bees, hornets, wasps etc. The principle works good from a
m ilitary standpoint, but only if you are on the attack. From a defensive standpoint, once
the superior force decides to attack, if you don’t counter attack, you’ve lost before the first
shot was fired.
Sadly, businesses who went looking to boost sales, discovered the failings of The
Swarm Principle. They found out that if they had actually gotten all of the sales that tried
to get through they wouldn’t need to boost at all. W ithout an operating system that had
both clustering and a distributed transaction m anager built into its core, many sales were
lost when these replicated nodes and services went down. They weren’t stolen by
com petitors or identity thieves, the node which was supposed to process them grabbed the
m essage, then promptly jum ped off a cliff. When the custom er didn’t get a response
within a reasonable am ount of time, they logged into a different vendor’s site to place their
order.
M any of the com panies which have m ade this discovery are beginning to move m ore
and m ore of their W eb back onto the OpenVM S cluster. Som e are reconfiguring PC based
W eb servers to do nothing m ore than serve up pages and build m essages for the OpenVM S
cluster to process. Others are m oving the W eb server itself back onto OpenVM S to get a
completely stable and robust platform for order processing and custom er service.
To answer the question “W hy Java?” is to understand why you, as a seasoned
developer with other languages on this platform , are being asked to learn Java. The
answer is two fold. Management wants to convert all of the core business systems to Java
in order to get som e use out of the W eb developers they have on staff when they are not
developing W eb pages. While they know Java, they have expressed little to no interest
in learning the applications of the core business systems. The second fold is that once the

Introduction

I-3

W eb servers m ove back onto the cluster, you, the core systems developer, are going to have
to design and develop W eb services from a systems, rather than a stand alone W eb page
perspective. The PC based W eb page writers sim ply aren’t capable of this.

I.2 Approach of This Book
You may have guessed from the opening section of this book, that it won’t be like any
other book you pick up on Java. Virtually every book on Java which I have either bought
or read starts you off w ith a handful of stand alone classes, then imm ediately drops you
into W eb page developm ent. In “Volum e 1", we won’t even cover W eb page creation or
development. At some point, I m ay write a “Volum e 2" which covers that portion of Java
from the OpenVM S perspective, but it is not currently in m y plans.
W e are going to cover the ugly side of Java which only gets a casual mention in most
other books, JNI (Java Native Interface). As an application developer porting a core
business system from one of the languages we previously covered to Java, you will face
JNI on a regular basis. It is m y hope that the source code provided both in this book and
on the CD will jum p start your application porting. You should be able to either use
directly, or steal heavily from the source this book provides.
The native interface is a back door provided in the Java language to m ake it more
usable. U sing this back door typically requires m ore skill than m ost people using GU I
developm ent tools possess. You have to program in C or C++. M ost Java developers w ait
for some serious chip-head to produce a new VM (Virtual M achine) w hich allows them to
access the hardware and operating system features directly from Java. Others buy a
m iddleware set of classes and saddle their com pany with a never ending support contract.
M y assum ption in this book is that you don’t have the luxury of waiting for a new
OpenVM S friendly VM and don’t want the never ending support contract which com es
from yet another third party product, you need to start porting today. In fact, creating a
VM which is OpenVM S specific is actually a violation of the Java license. HP could create
a com plete set of OpenVM S specific classes which gives Java developers com plete access
to the beauty of OpenVM S, but I wouldn’t hold m y breath waiting for that to happen.
Once we get through the obligatory basics of Java, we will jum p straight into the JN I.
Our first venture into the JN I will be accessing Run Tim e Library and System Service
calls from Java. Once that is done we will write JNI code to access the RM S indexed files
used in our M ega Zillionare application. After that we will once again em ploy JNI to
access FM S. Once all of the steps are taken, we will develop the RM S indexed file version
of our application in Java. Finally, we will m ove on to the sam e application using RDB.
There won’t be as m any chapters in this book because we are covering only one language
and m oving at a m uch faster pace. I had to lay a lot of ground work in the first book.
Now, I can make you jog, if not run.

I-4

Introduction

I.3 Prerequisites for This Book
It is assum ed that you have in your possession a copy of “The Minimum You Need to
Know to Be an OpenVM S Application Developer” ISB N 0-9770866-0-7.
(Hereafter
referred to as “Book One".) It is also assum ed that you have read that book and are at
least som ewhat com fortable with developm ent on the OpenVM S platform. I will not be
spending m uch, if any, tim e discussing the concepts covered in that book. You are
expected to either know them , or look them up in that book.
You m ay wish to get your own Alpha machine and Hobbyist license. This w ill let you
break things any way you want. While you could shop around on Ebay and hope against
hope you bid on a m achine which was correctly configured, I would highly recomm end you
contact Island Com puters (www.islandco.com) to get a m achine correctly configured. Then
all you have to do is install your Hobbyist m edia and licenses. Many of you m ay be quite
com fortable assem bling PC’s from scratch, but you have to be a little m ore selective with
the hardw are you get for an Alpha.

I.4 O btaining and Installing Java
Hopefully, you are all corporate em ployees with system s m anagers keeping your
OpenVM S m achines properly configured. In a com m ercial environm ent softw are and
service contracts lead to CD’s showing up in the m ail with the latest ECO’s and software
upgrades. I believe ECO stands for Engineering Change Order, but have used ECO for
so long I cannot say for certain. This is the term used to describe all fixes and
enhancem ents. When you wish to install the latest version of Java for OpenVM S you need
to be at the current ECO level for it.
W hile it is true that Java does ship with OpenVM S, the version on m y m achine did
not have the javah tool. This could have been a bone headed m ove on my part during the
install of the products, or it sim ply m ight not have been included with the Hobbyist m edia.
In either case, the version which was installed w as 1.1.8-5 and the current version was
1.4.2.
Do not skip the step of dow nloading and applying all of the ECO’s. Lots of people try
to do this and it hurts them . I obtained my Java stuff from the following link:
http://h18012.www1.hp.com /java/download/ovm s/1.4.2/sdk1.4.2_patches.htm l
W hile you could go to w ww.hp.com and look for Java stuff, I recom m end you start off
at www.openvm s.org when researching Java for your machine. The site is a valuable
resource for any OpenVM S developer, and its links are usually pretty current.
Be careful when you start to dow nload ECO’s and install them in the correct order.
Som e of them are 40+M EG in size (assum ing you are running 7.3-1 which is the current
Hobbyist version of OpenVM S). You m ay need a download m anager or a very forgiving
ISP. The other option is to contact HP directly and purchase the CD’s containing ECO’s

Introduction

I-5

and Java for your m achine. From a sim plicity standpoint, that last option is the best, but
it depends on the depth of your pockets for this adventure. The instructions for applying
the ECO’s are pretty straight forward. They appear on the Web site where you dow nload
the needed files.
Another thing you will want to download and install from HP is the M ozilla W eb
browser and email package. You will want the browser so you can open the Java
docum entation.
Once Java is installed, the Java docum entation is found in
SYS$COM M ON:[JAVA$1xx.DOCS]IN DEX.HTM L where xx = your version. Please note
that you will need to enable DECW indows on your system console, or have an X-windows
term inal em ulator in order to run the browser. You cannot run the browser from a
standard VT character cell interface.
If you wish to be an enterprising little geek, you can enable NFS services on your
Alpha m achine, obtain an NFS client for your W indows m achine, and m ap the
docum entation directory into your local m achine. This w ill let you open the HTM L files
from your PC browser. Telling you how to set that up is currently beyond the scope of this
book. There are also very few “free” NFS drivers/clients available for the W indows XP
platform at this tim e. If you are connecting to your OpenVM S m achine from Linux, you
m ay have an easier time of it.
Once you have downloaded either directly to your OpenVM S box or FTP’ed it from
your PC you can run the installation process. Here is the session from m y m achine:
$ set def dkb200:[scratch]
$ run dkb200:[eco]DEC-AXPVMS-JAVA142-V0104-24P2-1.PCSI_SFX_AXPEXE
UnZipSFX 5.40 of 28 November 1998, by Info-ZIP (Zip-Bugs@lists.wku.edu).
inflating: DEC-AXPVMS-JAVA142-V0104-24P2-1.PCSI
$ product install *
The following product has been selected:
DEC AXPVMS JAVA142 V1.4-24P2

Layered Product

Do you want to continue? [YES]
Information has been saved to allow you to uninstall the following patches:
RECOVERY DATA SET 001 created 9-JUL-2005 17:13:10.69
-------------------------------------- -------------------------------------PATCH
APPLIED TO
-------------------------------------- -------------------------------------DEC AXPVMS VMS731_PTHREAD V4.0
DEC AXPVMS VMS V7.3-1
-------------------------------------- -------------------------------------RECOVERY DATA SET 002 created 9-JUL-2005 17:12:05.81
-------------------------------------- -------------------------------------PATCH
APPLIED TO
-------------------------------------- -------------------------------------DEC AXPVMS VMS731_DCL V5.0
DEC AXPVMS VMS V7.3-1
-------------------------------------- -------------------------------------RECOVERY DATA SET 003 created 9-JUL-2005 17:11:09.67
-------------------------------------- -------------------------------------PATCH
APPLIED TO
-------------------------------------- -------------------------------------DEC AXPVMS VMS731_TDF V5.0
DEC AXPVMS VMS V7.3-1
-------------------------------------- --------------------------------------

I-6

Introduction

RECOVERY DATA SET 004 created 9-JUL-2005 17:09:47.54
-------------------------------------- -------------------------------------PATCH
APPLIED TO
-------------------------------------- -------------------------------------DEC AXPVMS VMS731_ACRTL V4.0
DEC AXPVMS VMS V7.3-1
-------------------------------------- -------------------------------------*
*
*
*
*

If you continue, recovery data for the patches listed above will be deleted.
The deletion of recovery data does not affect the installation status of
patches applied to products that are not participating in this operation.
However, continuing with this operation prevents you from uninstalling
these patches at a future time by use of the PRODUCT UNDO PATCH command.

Do you want to continue? [NO] yes
Configuration phase starting ...
You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.
DEC AXPVMS JAVA142 V1.4-24P2: JAVA for OpenVMS Alpha
Copyright 2003 - 2005 Hewlett-Packard Development Company, L.P.
Do you want the defaults for all options? [YES]
Do you want to review the options? [NO]
Execution phase starting ...
The following product will be installed to destination:
DEC AXPVMS JAVA142 V1.4-24P2
DISK$SYS:[VMS$COMMON.]
Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...90%...100%
The following product has been installed:
DEC AXPVMS JAVA142 V1.4-24P2

Layered Product

DEC AXPVMS JAVA142 V1.4-24P2: JAVA for OpenVMS Alpha
Consult SYS$COMMON:[JAVA$142.DOCS] for the Release Notes for this product.

$DIR SYS$COMMON:[000000]
Directory SYS$COMMON:[000000]
JAVA$142.DIR;1
JAVA.DIR;1

1/18
1/18

9-JUL-2005 17:22:26.42
17-NOV-2004 11:11:08.18

Each version of Java now has its own directory in SYS$COM M ON. Long ago things
were kind of scattered. You m ay wish to add the following line to your LOGIN.COM file
or to SYLOGIN .COM if you own the system :
$ @sys$common:[java$142.com]java$142_setup

Introduction

I-7

I.5 M ajor Pitfalls of Java on O penVM S
I highly recom m end that you poke around on www.openvm s.org and find the
dow nloads for ODS-5 prior to doing any developm ent w ith Java. There is a procedure for
converting your disk drives to OD S-5 (from OD S-2) listed with the download. W ithout
trying to get too technical, using ODS-5 (which you would need if you installed M ySQL
when we covered it in our previous book) allow s for m ixed case file nam es and a more
peaceful existence with opensource software.
Java is a case sensitive language. M ost of you will say “So what, wasn’t C?” Yes and
no. C was case sensitive within the language, but converted all of its entry points to upper
case. Som e of you m ay rem em ber m y debugging tip about the debugger not being able to
find your function nam es w hen you tried to set a break point typing in lower case.
Java is case sensitive outside of the com piler. W hen you declare a class it is
customary to used m ixed case nam es. W hen Java attem pts to run your P-com piled class
from within the VM (Virtual M achine), it looks for a file nam e m atching the class nam e
in exact case. You can either break tradition and w ork com pletely in upper case, or you
m ust get used to putting quotes around your file nam es w hen using the tools. This pitfall
exists on all stable and m ature platform s w here Java is ported. It isn’t a problem on the
lesser platform s.
Another m ajor pitfall with Java is that it is an sem i-interpreted language. M ost call
it an interpreted language, but I do not. You P-com pile Java source code into a syntax the
VM understands. The VM then interprets the P-com piled code at run tim e. While m any
will lam ent about the perform ance penalty of interpreting code, I won’t bother. M y issue
with the VM is that you can’t use it from within the safety and security of an ACM S
application.
Yes, you can set up a C program or function to call Java on OpenVM S, but once you
do that, you are running inside of the VM , not the controlled and secure environm ent of
ACM S. At least that is m y opinion. Should the Java VM die spastically without
com m unicating its death back to the caller, your server will sit idle waiting for a response
until it has reached the configured tim e out param eter. Then, and only then, will ACM S
kill off the task and start a new server to handle the message/task queue entry which was
being processed by the previously existing server. Adm ittedly, it is a small beef. We face
the sam e problem when we are accessing a relational database other than RDB.

I-8

Introduction

Page left blank intentionally.

Chapter 1

Basics of Java
1.1 A Little Bit of H istory and Concept
Don’t worry, I’m not going to bore you to tears re-hashing the sam e history lesson
every other Java book feels com pelled to provide. Not my style. You can read about that
for free on-line, or you can buy one of the oh-so-num erous books on Java which will burn
an entire chapter covering the history.
First, let m e ask for a show of hands, or w hatever lim bs you happen to possess, “How
m any of you consider yourself descent, good or seasoned C++ developers?” A very special
form of H ell waits for you while learning Java. “How m any of you consider yourself
comfortable or good with pointers in either C or C++?” Ah, one or m ore chem ical
dependancies are in your future learning this language. Choose your poison now!
This m ay not come as a surprise to you, but I’m not the biggest fan of this language.
Having spent way too m any years coding in C and C++ on viciously underpowered
platform s tw eaking cycles out of loops, I got really good with those languages. (O kay, I’m
a lot better with C than C++, at least according to the purists.) This language offended
m e in many ways. While I am som ewhat functional w ith the language, I am by no m eans
an expert, and avoid it when possible. (I’m still trying to figure out how I got talked into
writing this book. It sure wasn’t the publisher, because I’m self published!)
I think the biggest source of problem s I and m ost other C/C++ program m ers have with
this language are rooted in the syntax and where the language cam e from. Java was not
originally developed to be a W eb language. That happened when marketing got involved.
Java was originally developed to be an em bedded system s language. The kind of system
which exists in your m icrowave, VCR and later m odel autom obiles.
This concept wasn’t too bad at the tim e it w as developed. Having done some near
em bedded developm ent m yself in the early days of pen computing under DOS (don’t ask!),
I can tell you that state of RTO S (Real Tim e Operating System s) for em bedded use was
not good. Most shops had a collection of routines they kept using and tweaking with each
new project, but com m ercial RTO S were way too expensive and not m uch cleaner. Alm ost
everybody was hacking in assembler, with only the high end shops using C. (Ironically,
that’s pretty m uch the way it was w hen I last looked at the em bedded m arket as w ell.)
In truth, the concept was phenom enal. Rather than bread boarding together a CPU ,
som e RAM , an EPROM and som e IO devices; there were going to be these prepackaged
chips containing all of that along with a VM which understood Java. These single chip
m achines were going to be built in volum e and used for everything because they would be
cheap enough.
That really was a nice idea. It m ay even happen at som e point. I just don’t see it
happening as long as there are enough grizzled old tim ers still working. Too many of
them know how to hook together a 4-bit or 8-bit CPU, som e RAM and som e IO along with
m any years w orth of hand tuned assem bler. W hen they get done, it has a production cost

1-2

Basics of Java

m easured in cents, not dollars. Higher end appliances, like cell phones and PD A’s are
probably already using the once planned em bedded Java. I just don’t see it working its
way into your VCR or DVD player any tim e soon. Just how m any brains do consum ers
who leave the clock flashing 12:00 really need their VCR to have?
W hen Java was being created, the creators wanted it to be quickly adopted. At least,
that is the reason I’ve always been given when I asked w hy they used the syntax of C++.
M y personal opinion is that they would have gotten far m ore support from seasoned C/C++
developers if they had invented a completely new language syntax, or used something like
FORTRAN.
The reason for this belief is mind set. When you pull up a screen of code and it looks
like either FO RTRAN, BASIC or COBOL you im m ediately go into the m ind set for that
language. Every seasoned developer does it. You don’t even know you do it. W hen you
pull a Java source file up in your favorite text editor, you im m ediately go into C++ m ind
set, then are constantly frustrated by what is m issing.
Had there not been a rash of GUI pick and point tools developed early on for Java, I
think the language would have died on the vine. That’s m y personal opinion. I will back
that up w ith a test you can perform at your com pany. Ask som eone that calls them selves
a Java program m er at your com pany to develop an application without using any GU I
developm ent tools. Tell them to hand code everything in a text editor. No drag and drop
components. Make it som ething sm all, like our Mega Zillionare sam ple application. What
you will find is that m ost of the Java program m ers are really GUI tool users who happen
to know enough of the Java language to tweak things here and there.
Each and every tim e I need to discuss the syntax of Java with som eone I have to vent
m y frustration so com m unication can occur in a productive m anner. Rem em ber when I
said the C++ program m ers had a very special Hell waiting for them , well here it is: You
will be com pletely consum ed by the belief that Sun had a bunch of developers sitting
around who were physically incapable of learning C++, so they wrote a com piler which
handled as m uch as those developers could understand and tried to do the rest for them .
I know that som e very learned people worked on the language and that they are
considered way sm arter than m e. That’s okay. I’m not the only C++ developer I’ve m et
who has the exact sam e feeling. I’ve even seen it expressed in far m ore politically correct
term s throughout the years in geek m agazines. Early on in its existence I even read som e
interviews with the author of the language w here it w as stated they wanted to rem ove bad
stuff out of C++. During the evolution of Java, a lot of the bad stuff got added back in
because you sim ply couldn’t live without it. Let’s spend part of our history and concept
tim e discussing the bad stuff.
Rem em ber back in the first book when talking about C++ and I told you I couldn’t
rem em ber what the default protection was in a class? That was not com pletely honest.
I do have lucid m om ents from tim e to tim e where that knowledge random ly surfaces. If
you never knew it, then I suggest you don’t bother learning it. The reason I suggest that,
and the reason I don’t remem ber on a regular basis, is I have had to work with Java upon

Basics of Java

1-3

occasion. The default protection m ethod is different under Java. It is best you never learn
what the default protection method is, and always code; public, private or protected.
Java was created back when “goto-less” program m ing was all of the rage. Java even
went so far as to reserve the “goto” phrase as a keyword so other VM writers couldn’t add
it. There is one thing you can always say about a “goto”. Code a big enough and complex
enough program with lots of iterative changes handed out by the users, and you will need
it. The very quiet replacem ent for this bad thing was the labeled “break” and “continue”
statem ents. Java got rid of the “goto” keyword and replaced it w ith tw o synonym s for
“goto”. (W hen m aking that last statem ent in a bar around program m ers whose religion
is Java, it is advisable to wear m achine washable clothing. It is good for at least one
thrown drink and usually a fist fight.)
One of the biggest sources of bugs in code written by C and C++ developers is pointer
usage. Many developers learning the language sim ply don’t understand the concept. This
leads them to use uninitialized pointers and write over random sections of m em ory. The
other problem is that they allocate a big chunk of mem ory and forget to free it. If you are
working on a robust operating system , this last little bit isn’t a problem for your
application. Once your process is exited the operating system will clean up the allocation
you forgot to free. On lesser platform s it’s a real problem . Even after your process exits,
that m emory is still allocated.
Java sought to solve both of these problem s. The first solution w as pretty drastic.
They rem oved pointers com pletely from the language. The second solution w as built in
garbage collection. W e discussed garbage collection som e in the first book when talking
about relational databases cleaning up deleted rows in its tables. This garbage collection
has to do w ith the freeing of unused item s in mem ory, much like C++ does when objects
go out of scope. Java went a whole lot farther. It provides no “delete” operator. When
working with C++ you have both “new” and “delete” to give a program m er nearly com plete
control over object life tim e. Java, only lets you control w hen an object is created. It has
to go out of scope, then wait for garbage collection, to actually be deleted. (Som e
developers refer to this as “going out to the curb” since that is where garbage pick up
occurs for suburban residents.)
Another bad thing that went aw ay was m ultiple inheritance. Right here is pretty
m uch w here I get that foul taste in the back of m y throat that just won’t go aw ay. It is
also the point w hich leads m e to the opinion about a bunch of developers that couldn’t
learn C++.
Let m e describe multiple inheritance in plain speak. Multiple inheritance is a concept
in C++ (and m ost other OOP languages) which lets you create a shiny new object by
inheriting all of the inheritable properties of m ore than one other object. These objects
don’t have to have any relation what-so-ever. They can be at different levels in their own
inheritance trees. How anyone m anaged to write a com piler specification for that I’ll
never really understand.

1-4

Basics of Java

Don’t go letting your eyes glaze over just now. This w as the m ost powerful tool C++
gave us. It allowed you to solve unbelievably complex problem s. I don’t want to give you
a contrived exam ple, and we aren’t covering C++ in depth in this book. Being able to
com bine m ultiple unrelated objects into a single new object definition was a tool which
was indispensable with C++. Java learned its lesson by leaving it out. The later
definitions of the language added it back in, but they don’t call it m ultiple inheritance,
they call it “interfaces”.
Oh, what a horrible choice of nam es “interfaces” was. This is a com pletely different
definition of “interfaces” than m ost C++ program m ers use. With respect to Java an
interface is a collection of constants and abstract methods. They are not classes. An
interface doesn’t declare any usable data item s. W hen you choose to im plem ent an
interface within a class you must provide all of the m ethods declared in the interface and
they m ust be at the same protection level as declared in the interface. When you declare
your class you can inherit from only one other class, but you can im plem ent m any
interfaces. When C++ program m ers talk about interfaces to classes they are talking about
the externally available list of m ethods and m em bers. In C++, every class has an
interface. With Java, only a class that “im plem ents” an interface has an interface. (The
keyword is im plem ents not im plem ent.)
If your eyes glazed over reading that last paragraph, it’s okay. There is a reason I
didn’t talk m uch about interfaces when we discussed C++ in the last book. I didn’t want
to get you far enough into the language of C++ to m ake your journey through Java
painful.
Java w as originally intended to be pure OOP (Object Oriented Program m ing).
Everything, short of the m ost basic data types, is a class. You can’t even have a stand
alone “m ain()” function as you can with C++. The philosophy behind C++ was you could
use it as a better C until you got com fortable enough with OOP to start doing more with
OOP. With Java, you have to do a running cannon ball into the pool of OOP. There
sim ply is no other way.
Nearly every book on Java you buy will show you how to w rite applets in Java. In
order to run the applet you will need to write som e HTM L and use a browser. This book
will not bother with applets or browsers. The concept in this book is how to convert your
existing core business applications to use Java, yet still preserve your investm ent in the
m ost stable platform on earth. You will also want to preserver your investm ent in
character cell term inal em ulators and character cell term inal em ulators cannot run a
brow ser.

Basics of Java

1-5

1.2 D ata Types
Java supports a limited set of core data types. The distinction betw een a core data
type and other data types is the lack of class. Core data types are understood directly by
the com piler without using any library functions. All other data types are class definitions
and require the run time libraries. There are only 3 groups of core data types: num eric,
boolean, and character. Do not leap to the conclusion that character is how you deal with
string values in Java. W hile that is true for m any 3GL’s, it is not true for Java. To deal
with string data types, you have to use the String class.
During the course of the first book I m entioned several tim es the problem s of porting
data from one hardware platform to another. Som e m achines are Big Endian and others
are Little Endian. Additionally, many m achines developed their own proprietary num eric
data types for handling floating point values. Java solved that problem with the VM .
Every data type has the exact sam e byte order no matter what m achine the VM was
im plem ented on. This m eans that if you create a flat data file using raw num eric values
on one m achine, it can be read by Java on another m achine. All bets are off w ith indexed
files that are native to a specific platform . The Java language itself doesn’t provide any
indexed file support.
One of the biggest selling points for m ost GUI developm ent environm ents is that they
give you som e form of indexed file library along w ith database access. The catch was any
m achine you wanted to use this data on had to have the database engine, or at least the
GUI development environm ent installed. As I said, Java is some of the most expensive
“freeware” you can get. If you surf around on the W eb you can usually find som e B-tree
indexed file system s written completely in Java. Good luck finding free versions of them
though, since m ost developers have bad habits like eating and living indoors.
There are six core num eric data types supported by Java.
byte
short
int
long
float
double

tiny signed integer
short signed integer
signed integer
long signed integer
floating point num ber
double precision float

8-bits
16-bits
32-bits
64-bits
32-bits
64-bits

Rem em ber that there are eight bits to a byte on most machines these days, then look
at the following C code.

1-6

Basics of Java

TEST_SIZES.C
#include <stdio>
#include <stdlib>
int main (int *argc, char **argv)
{
printf(
printf(
printf(
printf(

"Size
"Size
"Size
"Size

of
of
of
of

long %d\n", sizeof(long));
double %d\n", sizeof(double));
short %d\n", sizeof(short));
int %d\n", sizeof(int));

return 1;
}
$ run test_sizes
Size of long 4
Size of double 8
Size of short 2
Size of int 4

W hen working with C a long is 32-bits. The long data type in Java corresponds to the
quadword data type I spent so m uch tim e harping about during the first book. Get this
difference down.
Since the core num eric types can be restrictive to som e developers, som e additional
num eric classes were added to the language. These classes are BigDecimal and
B igInteger. They can be used to create num bers of arbitrary width and precision. W e
won’t be m essing with them in this book. Just rem em ber they are there in case you need
to create som e 128-bit floating point values.
W ith respect to floating point data types, Java stole some pages from the FORTRAN
specifications. It has specific values for NAN (Not a Number), Negative Infinity and
Positive Infinity. You get NAN results when performing illegal operations, such as
dividing by zero or m ultiplying by infinity. Since division by zero happens a lot in the
business world, this is a good thing.
Boolean is a data type m ost of us think we should know, but we don’t. Under m ost
languages boolean values are simply integers that use either positive/negative or 1/0 to
indicate true/false. Under Java there is a specific boolean data type which can have only
true or false as its value. If you forget to initialize your boolean it is initialized to false.
Keep in m ind that Java provides a default initialization for all class data mem bers,
but not locally scoped variables. W e will discuss m ore on this later, or you can open the
previous book and skim through the scope discussion for the C/C++ chapter.
The character data type is the one which trips up m ost developers coming from other
languages. When w e covered BASIC, FORTRAN, COBOL and C/C++ in the previous book
a character was always 8-bits wide and held an ASCII value. W ith the exception of the
currency sym bol, the representation of these characters w as standard across platforms for
the first 127 values. The last 128 characters w ere a free-for-all dependant upon the active

Basics of Java

1-7

code set on the machine and what a developer chose to load for them . (W e did not cover
loading different values in the last 128 characters. That is som ething usually only done
by PC developers to draw graphics.)
The creators of Java decided they w anted it to be an international language, not follow
existing trends. As a result the character values used by Java are 16-bits wide and are
Unicode characters. For the m ost part, Unicode kept the first 127 the sam e as ASCII,
sim ply because of the installed base. I won’t go into the ins and outs of Unicode. Those
of you wanting to know m ore about Unicode can visit http://www.unicode.org.

1.3 Everything is a Class (alm ost)
Since the creator(s) of Java wanted it to be a pure OO P language, alm ost everything
is a class. The previous section covering the core data types is just about the only thing
which isn’t a class, but can only be used from within a class. Your application has to have
one prim ary class with a “m ain()” m ethod declared in it in order to run.
The first class you need to get fam iliar with is String. Technically the full nam e of the
class is “java.lang.String”, but since it is the core API you can declare instances of it just
using String. When you place a quoted string in your source listing the com piler doesn’t
just create an array of characters, it creates a String object (instance of a String class) to
contain those characters. Those characters will magically be flagged for deletion whenever
they go out of scope.
Let m e go into this just a little further.
String mantra = “I am a real programmer”;
mantra = mantra + “, I studied logic without a language.”;

After these statem ents execute there are actually three string instances and one
StringBuffer instance in m emory. At some point in tim e Java will get around to garbage
collecting the tem porary StringBuffer object that was used to concatenate the two quoted
strings together. In order to understand why that is, you need to know one thing about
String objects; they can’t be changed. Oh, we add, subtract, change and otherwise
m utilate strings in our code, or so it appears. Behind the scenes Java keeps m aking new
ones. A StringBuffer class is the dynam ic class of string which allow s for string
m anipulation. Once it has been m anipulated the result is given to a String object and will
stay as it is until the garbage collector tosses it back on the heap.
I know that the above exam ple was a lot to swallow this early on, but we shall
endeavor to persevere. The next section will help sweep it up for you.

1-8

Basics of Java

1.4 Reference not Pointer
W hen w e covered C++ we talked about passing objects by reference. Where a
reference was a very special kind of pointer which m ade the object appear as if it were
local to the receiving m ethod (function). Java takes references to a new level. Everything
which isn’t a core data type is a reference. In the previous exam ple, where the syntax
m ade it look like we declared a String object nam ed m antra, we actually declare a String
object of unknown nam e and m antra was a reference to that String object. This is a
difficult concept for m any developers.
To understand how we end up in this situation you have to rem em ber Java runs under
a VM (Virtual Machine). When we talk about com piling Java we talk about generating
a P-com piled file which the Virtual M achine understands. W hen we talk about com piling
our previously covered languages we talk about generating binary OP codes understood
directly by the CPU . As program m ers we tend to think our program is doing what we
coded. When speaking in term s of Java, this is not true. The VM is doing what we ask.
The P-com piled translation generated som ething along the following lines:
Hello VM . Go create m e a String object having the value of “I am a real program m er”.
W hen I refer to that object in the future I am going to call it mantra. Feel free to delete
it when you don’t think I need it any m ore.
The key phrase in this conversation is “when I refer to that object”. There in lies the
fundam ental principle of Java. Your “program ” doesn’t own anything, it never has, and
it never will. It is a slave begging for favors and services from its m aster, the VM . When
the VM decides you no longer need som ething, it takes it away without telling you.

1.5 The Sandbox
This m aster-slave relationship lead to a concept you will hear talked about quite a bit
by Java developers, the sandbox. W ith version 1.0 of Java the sandbox was introduced.
Code which was downloaded rather than written locally would run in a sandbox. What
that code could and could not do w as controlled by the SecurityManager object. The
abilities allowed by the sandbox change based upon settings you or your system m anager
tweak in the VM and by new releases of Java.
I’m bringing up the sandbox here, because as application developers, it is useful for
you to envision all code as running in a sandbox. That’s really the concept behind the VM.
One sandbox m ay have m ore toys than another sandbox, but it is really just a sandbox.
Those of you reading this who own cats feel free to conjure up a hum orous im age of the
Java sandbox and what is going on there.

Basics of Java

1-9

1.6 G arbage Collection
I need to discuss just a little bit about garbage collection before m oving on to m ore
interesting topics. At various places already I have m entioned garbage collection. This
is autom ated m em ory reclam ation. For lack of a better description, each little sandbox
keeps a list of objects it no longer needs. W hen the garbage collector makes its rounds it
looks at each sandbox and starts deleting item s off that list, returning mem ory to the VM
pool.
Since Java was originally designed for em bedded system s w hich are traditionally
underpowered, perform ance was of param ount concern. Besides wanting to elim inate
pointers, the creators wanted to rem ove the burden of freeing m em ory allocations from the
application developer. They placed that burden on the system s developer coding up the
VM . A lot of heated argum ents happened about where and when to do garbage collection.
U ltim ately, it was decided to have the VM launch a task at priority zero so it only got tim e
when the system was idle.
Developers from days gone by on OpenVM S remem ber fondly the N ULL process. You
used to be able to see it when you typed in the comm and:
$MONITOR PROCESS/TOPCPU

Alas, the N ULL process is now hidden away from casual observers. This used to be
a good guide in determining why your system seem ed sluggish. If the N ULL process was
getting a lot of tim e you knew the problem was disk IO. Either you had a “hot spindle” or
you had a pair of big jobs beating each other up trying to lock the sam e records. (A “hot
spindle” is a term used to describe a disk perform ing m assive am ounts of IO.)
W hen your OpenVM S box is running at 80% capacity or less, this m ethod of clean up
works well. The 80% is a num ber I learned back on the VAX hardw are. I don’t know what
the num ber is for Alpha hardware or Itanium hardware. I assum e it is now closer to 90% .
Regardless of where that magic percentage threshold is, or what platform you are on,
when you exceed it, all of those clean up tasks hooked into the idle process won’t get any
tim e.
W hat this m eans in term s of Java is that garbage collection will not occur.
Applications will continue running on the m achine, although they will seem sluggish, but
m em ory resources will no longer free up. That m eans that even when your application
finishes, the sandbox it ran in won’t go away because the garbage collector never got any
tim e to com e around and take out the trash. If one or m ore of the processes binding up the
CPU doesn’t com plete, you will eventually exhaust all virtual mem ory and things w ill
start crashing.
Those of you coming from W indows and U nix type environm ents will envision this as
a complete system crash. Nothing could be further from the truth on OpenVM S.
Rem em ber back in the first book where I made you look at UAF (User Authorization File)
entries? Every process runs under a user ID. Each user ID process has an amount

1-10

Basics of Java

available to them determ ined by the entries in the UAF for that user. If you are starting
and stopping a lot of Java program s under a standard user account when the garbage
collector is barred from doing its job, you will m ost likely be the process which crashes.
Look on the bright side though. When your process goes away, it will free up some CPU
cycles so the garbage collector can finally clean up after you.

1.7 N o Include Files or Preprocessor
One of the m ost abused concepts in the C language was the preprocessor. Developers
did nasty things with m acros that would collide with other m acros creating a com plete
debacle for the hapless coder trying to m ake two comm ercial libraries w ork together. C++
tried to help alleviate the problem by adding nam espaces to its language definition.
The creators of Java decided, w hen it came to header files, that dog won’t hunt. They
don’t exist in the language. But it didn’t take long for that idea to create its own little
train wreck. Without som e m ethod of inclusion from external sources, you couldn’t use
libraries together without cutting and pasting large am ounts of code into your source file.
Enter the “im port” statem ent. This isn’t like the #include directive you find in C, even
if it does look a lot like it. The im port statem ent allows you to bring in either specific class
definitions from packages, or entire packages.
W hat’s a package you ask? A package is a group of classes that get com piled into a
package. (Nice W ebster, eh?) At the top of each class source file you want to be part of a
package you stick in the statement “package som e.package.name;” Once you have
com piled all of the classes for the package, and built the package, you can then reference
it in your application source file by coding “im port som e.package.nam e.SepcificClass;” to
get only one class or “im port som e.package.nam e.*;” to get the entire package.
W hile it m ay seem easier to just im port the entire package, don’t. These aren’t header
files and Java isn’t polite like C. W hen working with C you could include every header file
you though you might need and as long as they didn’t declare any global data, they had
no impact on your executable size. W ith Java, your P-com piled little class suddenly
becom es an 8000-lb. Gorilla when it loads.
Notice the format of the package nam e with all of the dots in it. This is one part of
Java that seem s to be tied completely to the W eb. The convention for nam ing packages
is to invert your dom ain nam e and add som e stuff. If you happen to be a com pany or
person with a registered dom ain nam e, this works out well. For those of us working
internally, we have to cobble up a dom ain nam e on our internal network. The cobbled up
dom ain nam e I put on m y internal network is logikal.com. Packages I declare in this book
will be com.logikal.something.

Basics of Java

1-11

1.8 Constructors and Finalizers
Since we have a prerequisite that you have already read the previous book, you are
already familiar with the concept of constructors and destructors from the section on C++.
The constructor is tasked with allocating storage for the object and its core data item s. It
does not allocate storage for data item s which them selves are classes. The constructors
for those objects are tasked with that. If you don’t bother to code a constructor for your
class the com piler will generate a default constructor for you. Unless your classes are
sim ple, you m ay not like what it does.
If you code any constructor in your class definition, the compiler will not generate a
default constructor for you. This means that if you code a constructor which accepts
param eters to populate data item s with, you will also have to code a version which accepts
no parameters if you want that functionality.
Your constructor has the sam e nam e as the class with no return value. You can
overload your constructors just like you can overload m ethods.
Remem ber when we discussed C++ in the last book w e talked about a destructor being
the sam e nam e as the class but having a “~” in front of it? Java decided to go its ow n way
here. Destructors in Java are called finalizers. They are actually a method nam ed
finalize() which accepts no param eters, but can flag exceptions it m ight throw. (W e will
talk about exceptions m uch later.)
Always declare your finalize m ethod as a protected void m ethod. This stops som eone
from being either malicious or stupid. If it isn’t protected it could be called from
anyw here. A finalizer m ethod is som ething people don’t code m uch. The reason is they
don’t do m uch. The compiler generates the code to flag all of the items for garbage
collection. The only things you wish to do in a finalizer is close files and release external
resources. A case in point would be the two classes w e declare for accessing RM S indexed
files in the previous book. The only thing they did was call the close() m ethod.

1.9 Arithm etic Operators
It w ill com e as no surprise to you that Java supports m ost of the arithm etic operators
from C. Here is a quick and dirty table for you. Precedence is in descending order with
one being the highest.
Operator
++,-+,*,/
%
+,-

Description
auto-increm ent, auto-decrem ent
unary plus, unary m inus
m ultiplication, division
m odulus (rem ainder)
addition, subtraction

Precedence
1
1
2
2
3

1-12

Basics of Java

Some of you m ay remember the little saying I im parted to you in the last book.
Please Praise
M y Dear
Aunt Sally

Powers Parenthesis
M ultiplication Division
Addition Subtraction

It still w orks here. I’ve yet to find a place where it didn’t work. Since modulus is
really a division it occurs at the sam e level. Java does not give us the “**” operator that
BASIC did for raising a num ber to a power. You have to use the power() function of the
m ath package.

1.10 R elational O perators
W e get the same set of relational operators with Java that we had in C/C++.
Operator
>, <, >=, <=

==
!=
?:

Description
greater than, less than,
greater than or equal,
less than or equal
equality
inequality
conditional operator

Precedence

5
6
6
13

Once again I m ust caution you to never use the conditional operator. It is short hand
for if-then-else. The item placed in front of the “?” is tested for truth. When it is true, the
value imm ediately after the “?” is the result. W hen it is false, the value following the “:”
is the result. As in C/C++ this is a very confusing operator for m ost people to read. My
personal opinion is that programm ers use it for job security. Using it elim inates a large
pool of people which could otherwise m aintain the code.

1.11 B oolean O perators
Java has the sam e set of boolean operators as C/C++ as w ell.
Operator
!
&
^
|
&&
||

Description
Not
Boolean AN D
XOR (Exclusive OR)
Boolean OR
Conditional AND
Conditional OR

Precedence
1
7
8
9
10
11

These boolean operators don’t work like their C/C++ counterparts. You can only use
them on variables of the boolean data type or expressions that return a boolean data type.
To add insult to injury, some of the bitwise operators are exactly the sam e as the boolean

Basics of Java

1-13

operators.

1.12 B itw ise O perators
Operator
~
<<, >>
>>>
&
^
|

Description
not
left shift, right shift
right shift as unsigned
bitwise AN D
bitwise XOR
bitwise OR

Precedence
1
4
4
7
8
9

One thing worthy of note here is the >>> operator. You don’t find this in many
languages. The reason for its existence is that Java doesn’t have unsigned data types. If
you right shift a signed numeric that has a negative value the sign bit keeps walking
down. This operator stops that from happening.

1.13 A ssignm ent O perators
As in C/C++ there is an entire fam ily of assignm ent operators. W e all know about the
“=”, but what m ost people forget is that you can prefix the equal sign with every one of the
arithm etic or bitwise operators. Only one at a tim e, of course, but that creates a great big
list of assignm ent operators.

1.14 Com m ents
Java supports the sam e com m ents as C/C++. This m eans you can use either /* */ to
enclose a com m ent or // to create a single com m ent running to end of source line. There
is also one very special com m ent indicator you will see. The com piler accepts it like a
com m ent, but another utility uses it to generate docum entation.
/** This is a javadoc comm ent line */
The com m ent starts w ith /** and m ust end with */. It can span m ultiple lines as with
a regular comm ent of /* */ type. When you feed a source file through the javadoc utility,
it scans the source looking for these special com m ents to create HTM L formatted
docum entation files.
W hile this is a nice idea, most developers, myself included, don’t write descriptive
enough com m ents to be used for docum entation. There have been various utilities in the
C programm ing world for quite som e tim e which used the sam e or sim ilar com m ent syntax
to generate docum entation. Granted they didn’t generate H TM L docum entation for W eb
usage. The W eb didn’t exist when those tools cam e out.

1-14

Basics of Java

1.15 Abstract Classes and M ethods
The world of O O P likes to let the original developer im pose rules on those to com e.
The biggest one of these rules is enforced by the keyword “abstract”. When you put the
keyword “abstract” on a class, it can contain only constants and abstract m ethods. No data
variables or implem entation code can exist for it. E very class which inherits from this
abstract class will be forced by the com piler or the run tim e environm ent to provide an
im plem entation for each abstract m ethod. The catch, however, is that the im plem entation
doesn’t actually have to do anything. You can m ake it a dum m y m ethod.

1.16 Inheritance
You receive a letter in the m ail from a law firm reading “After conducting a thorough
investigation of all sources we have determ ined you really are the sole beneficiary of
How ard H ughes’ estate totaling...” Oops! Not exactly the definition used by OOP. W e
discussed inheritance in Book One. The syntax and rules are som ewhat different with
Java.
Java only allows you to inherit from one class at a tim e. This is not to say that you can
only go down one level in classes. Our theoretical RM S classes from Book One could be
im plem ented in Java because each level only inherited from one other class. You can
continue chaining down until you lose your place, but you cannot inherit from m ore than
one class at a tim e. For m ost of you, this won’t be too bad. Only developers doing heavy
up front design tend to design applications or system s needing m ultiple inheritance.
Developers new to both C++ and Java tend to avoid designing their own inheritance,
and that is fine. There is m ore than one way to skin a rabbit. Many tim es, during m y
early days in C++, rather than creating a shiny new class inheriting from several other
classes, I sim ply created a class w hich had objects of other classes inside of it. Depending
upon what you have to work with and what you are trying to do, this can be a valid
approach.
Let m e try to clarify the previous statem ent by looking back upon our C++ application
from Book One. We kept the C++ version (both RMS Indexed and RDB) very close to the
C version to m ake jum ping the hurdle easier for those readers who had neither worked
with C or C++. The C++ O OP purists probably have a contract out on me now for showing
you an exam ple like that.
If we wanted to be a little m ore OOPish we would have created several C++ classes.
The first class would have been an FM S class containing m ethods for each FM S function
call, all of the needed workspace and FM S initialization. The RM S version already did
have a single class for each file we were working w ith. Then w e would have m ade the
entire application a class, em bedding objects in it for the FM S class and each file class.
This would have been far m ore OOPish than what I did.

Basics of Java

1-15

The elite purists would have developed an FM S class, a generic RM S indexed file class,
then inherited from those classes w hile creating a single application class. All procedural
type functionality would have been com pletely concealed inside of class m ethods and most
of the data for the class m ade private.
Don’t shake your head or laugh. I’ve seen it done. Upon rare occasion I’ve been forced
to do it when w orking w ith 3 rd party C++ application fram e works. You will run into m any
in the Java world who do developm ent just like that. Dam n the m aintenance
programm er, code speed ahead! Part of this m entality is forced upon you by Java itself.
Every application has to be a class with a main() m ethod. Every applet has to be a class
with a specific list of m ethods provided as w ell.
The syntax in Java for one class to inherit from another is quite different.
public static class MyClass extends MyBaseClass

The keyword “extends” tells the com piler to inherit from the single class nam e
following. The class M yBaseClass could also have a class inheritance buried in its
definition. I really don’t know how far back the lim it is. I do know that m entally, m ost
developers cannot grasp more than two levels back. GUI tools w ith class browsers remove
that burden from the developer. You can nest as deep as you want and just keep clicking
away to find the method you think you need.
You do need to be aw are of two other keywords when inheriting: this and super. These
keywords will be fam iliar to those of you who have done a lot of C++ coding, at least the
“this” keyword will be. Use the “this” keyword inside of class m ethods when referencing
class m em bers to indicate you want the class m em bers from this class. You use “super”
when you want the m em bers from a parent class.
At first blush it m ay seem really stupid to code m ethods inside of a class, yet access
the class m em bers via “this”. It all goes back to the OOP philosophy of planning for
inheritance. If one of your data m em bers was unfortunately nam ed “x” or “y” or som e
other com m on variable nam e, the poor Schm oe w ho inherited from your class to make a
better class, who happened to use the sam e m em ber nam es would be in a lot of trouble.
Perhaps they didn’t use those sam e nam es, but chose to declare local m ethod variables x
and y. Without the keywords this and super, they would have no m ethod of inform ing
Java that they wanted the variables from outside of local scope.
Be very careful when designing classes expecting to use this and super. These
variables cannot be used inside of static m ethods. The com piler will spit up if you try to
declare your classes in the sam e source file where a static m ain will be referencing them .
Let m e give you an exam ple which works to clear up m y above explanation.

1-16

Basics of Java

Dum m yClass.java
public class DummyClass {
public int
x;
public void printBoth() {
int x;
x = 22;
this.x = 7;
System.out.println( "local x is " + x);
System.out.println( "class member x is " + this.x);
}
}

// end printBoth method

// end definition of DummyClass

TestScope.java
public class TestScope {
public static void main(String args[]) {
DummyClass h = new DummyClass();
h.printBoth();
}
}

// end class TestScope

$ javac DummyClass.java
$ javac -classpath [] TestScope.java
$ java "TestScope"
local x is 22
class member x is 7

Adm ittedly we haven’t covered a lot of the Java language yet, but you should be able
to m uddle through these sim ple source files. In order to be able to show you how to use
“this” I had to declare m y classes in two separate source files.
Our first highlighted line shows you the class m em ber declaration of variable x. The
second highlighted line show s you the local m ethod declaration of a variable using the
sam e nam e. The rules of scope only let the m ethod printBoth() look at the local x variable
unless we use the “this” keyword to force it to look outside of local scope.
W hen com piling m y second class source file I had to use the -classpath com m and line
option to tell the com piler where it could find m y class definition. This was required since
I didn’t put the class definition into the default Java path or a JAR that Java knew about.
(Eventually we will get to covering JAR files so don’t w orry if you are unfam iliar w ith the
term .)
In order to run the class I had to put the name in quotes so the Java environm ent
would be able to deal w ith the fact the class file nam e w asn’t an exact case m atch. As you
can see from the output the local x value was 22 and the class m em ber x value was 7.

Basics of Java

1-17

1.17 Polym orphism
This big word is used to im press people w ho know nothing about it. I cannot
remem ber how m any m eetings I sat through in the early days of C++ where sales reps for
C++ developm ent products took it upon them selves to say this word as m any tim es as
possible with M BA’s in the room. It was even m ore entertaining listening to these sam e
people, whose eyes glazed over as soon as their attention was diverted from the four color
glossy overheads, try to use it in sentences for budget approval. To understand just how
entertaining it was you would have to rent one of the old Star Trek movies. I don’t
rem em ber the title, but it was the one where they cam e back to the past to find whales.
O ne of the sub-plots in it had Spock trying to learn how to use profanity, sputtering
phrases like “I will the Hell”.
Polym orphism isn’t new. The word is relatively new and cum bersome, but the concept
isn’t new. A polym orphic function cares little to nothing about the data passed into it.
From the earliest days of BASIC we had the PRINT statem ent. It didn’t care what kind
of native data type(s) you passed into it, sim ply found a way to print them . COBOL
program m ers had the DISPLAY statem ent which will print anything that isn’t a raw
binary format. Assem bler program m ers on the VAX platform had SYS$FAO(). All of
these are polym orphic functions, and none of those languages are considered OOP
languages.

1.18 Source Code O rganization and Style
It was a truly sad day when the Java docum entation and exam ples started to surface.
All of those C/C++ developers who placed the opening curly brace for scope definition on
the sam e line as the m ethod or class nam e, that were cast out of the C/C++ world for doing
that, apparently w ent to work on the Java project. This m akes for som e truly unreadable
code. It is also one m ore significant reason to put your opening curly brace on the line
below when working with C /C++ so you can tell at a glance what language you are
working with.
Source files for Java m ust occur in this order:
Packages
(If any)
Im ports
(If any)
Class statem ents
The first class must be the sam e nam e as the source file. The class MyClass must be
in a source file nam ed M yClass.java. W hile you can declare m ultiple classes in the sam e
source file, do not declare m ultiple public classes in the sam e source file. This is begging
for disaster, even if your com piler version will let you do it. You can have any num ber of
private or em bedded classes in this source file. Rem em ber back in Book One when we
were talking about nesting record definitions inside of record definitions vs. group
definitions? You can do the sam e thing with class definitions, only these definitions are
declared externally.

1-18

Basics of Java

1.19 M odifiers for D ata Types and M ethods
There are two groups of modifiers for data types and m ethods. You will always hear
this referred to as “data type” instead of “class”. In many situations you can use these
m odifiers on the built-in data types. The first group effects storage and lifetim e. The
second group effects access.
Storage and Lifetim e
abstract, final, native, static, synchronized, transient, volatile
Access
private, protected, public and the unnam ed default
W e have already covered abstract earlier in this text. This is in a large part equivalent
to the C++ keyword “virtual”. It flags classes and m ethods stating that there is absolutely
no im plem entation for them . You m ust provide the im plem entation when inheriting from
this class. Abstract classes can contain only constants and m ethods which are flagged as
abstract.
Final is a poorly chosen nam e. It m eans constant. You m ust initialize any variable
at the tim e of declaration when declaring it final and that is the last value it will ever
have.
Native is a m odifier we are going to beat to death with this book. It flags a m ethod as
being written in C. Write this day down. That is the only tim e you will ever read native
being described that way. Every book I have ever looked at uses the politically correct
phrasing of “im plemented in other languages, such as C”. That phrase scores pretty high
on the Bullshit M eter. Other than the javah tool to create headers for use with C, I don’t
know of any tool released with Java which will let you generate headers for CO BOL,
BASIC, or FORTRAN. If you ever find one, and it has been ported to OpenVM S, please
feel free to em ail m e. When people want to salvage code from these languages for use with
Java the standard answer is “write a bogus wrapper function in C to call your function
written in (insert language here).”
Static has som e really nice politically correct descriptions published everywhere
around the net and in print. These descriptions tend to rate very high on my Bullshit
M eter as w ell. This is how Java tells the world (and the V M ) that no matter how this
declaration looks, it really is global. W hen you declare a data item static in a class, only
one copy exists across all instances of that class.
Declaring data item s as static inside of a class definition is som ething the sober don’t
do unless they have consum ed a sufficient quantity of nicotine. The reason is you need to
tell Java just how to initialize the static variable with a special “static { }” area in the class
definition. You cannot initialize it in the class constructor because there is only one copy
of it everywhere. If you try initializing it in the class constructor it will be wiped out every
tim e a new object is created. The classic exam ple of static data items is reference
counting.

Basics of Java

1-19

TestStatic.java
public class TestStatic {
public static int theCount;
public TestStatic() {
// every time an object is created we
// bump the counter

}

theCount++;
// end testStatic constructor

protected void finalize() {
// wouldn't be a very usefull counter
// if we didn't drop it every time we
// killed off an object.

}

theCount--;
// end finalize method

static { theCount = 0; }

}

// end class TestStatic

In the above class definition you see how we declared our static variable. In the class
constructor we increm ent it. In order to be an actual reference counter instead of just a
creation counter, we have to decrem ent the count when an object goes away.
The very last highlighted line is critical for us to discuss. I, didn’t need this. Most of
the tim e you won’t. By the tim e you do need it, you won’t rem em ber how to do it. Java’s
default value initialization tends to m ake people sloppy, this is the one thing I really hate
bout Java. As long as you are always declaring num eric static item s you want initialized
to zero, you will never need that last line. Java does this for you. The first time you need
to declare a static String item w ith a value other than null you will be fine since you will
find the way to get the value in during declaration. If you were lucky enough to be a C++
programm er before you learned Java you will remember that C++ forced you to provide
a value at the m oment of declaration. If we needed to start with the value 8 we could do
as follows:
TestStatic.java
public class TestStatic {
public static int theCount = 8;
public TestStatic() {
// every time an object is created we
// bump the counter
theCount++;
}
// end testStatic constructor
protected void finalize() {
// wouldn't be a very usefull counter
// if we didn't drop it every time we
// killed off an object.

1-20
}
}

Basics of Java

theCount--;
// end finalize method

// end class TestStatic

M ost of the books I have seen on Java over the years tend to show the first m ethod of
initialization because that one is Java’s own. The second m ethod, highlighted above,
shows the w ay you w ould declare each and every static class m em ber when w orking with
C++. The m ethod also works for Java. I hum bly advise you always use this last method
and always provide a value.
Synchronized applies only to m ethods in a class. If you are unfortunate enough to
have to use threads in Java you will live and breath the synchronized keyword. This
restricts m ethod execution to only one thread at a tim e. Usually you are doing a lot of
complex m ath or other such thing which creates a lot of tem porary variables that are not
thread safe. Putting synchronized on a m ethod doesn’t also m ake it static. In most
threaded applications you will find synchronized used in lock step with static on m em ber
m ethods.
Transient is probably one of the m ore politically incorrect qualifier nam es you will find
in Java. Programm ers com ing from other 3GL languages are used to referring to stale,
left over data drifting through their application as tram p or transient data. When you
speak of the transient m odifier for Java it means “do not save”. By itself the m odifier is
of little use. It only takes effect when you are serializing data. (Serializing is the ability
of an object to store itself on disk in som e special form that can later be read back in, not
necessarily by the sam e application.)
Volatile basically m eans all bets are off. Since m ost Java developers are OOP purists
they typically only put this qualifier on a variable written to by multiple threads. Much
of the original intention was to indicate that this variable or region of m em ory would be
changed by external hardware or the operating system .
The accessibility options are kind of strange for developers com ing from C++, prim arily
because of the “default” access. Mem bers and m ethods declared private do not get
inherited by other classes, they are only visible in the class which declared them . This
part, at least, is consistent with C++.
Protected m em bers and m ethods get inherited by any class using the class as a base.
Oddly enough, any class in the sam e package has access to them . I know we haven’t really
discussed packages in any significant detail yet, but you are aw are that a package is a
group of things stuffed into the sam e container. In a w ay you could look at a package as
a library, but that will cause a lot of confusion when you try to decipher what these access
m odifiers control.
Public is a free-for-all. Anything can access it from anywhere as long as they provide
a path to it. Public m em bers and m ethods get inherited. They can be access anyw here
from inside or outside of the VM . This is w hy the m ain class in every java source file
needs to be declared public. So you can invoke it from the comm and line.

Basics of Java

1-21

The default access is the one which causes a lot of hardship. When you are working
within the sam e package or directory it is just like public. M any developers initially
confuse it with public access, but it is not. Classes which are not part of your class cannot
inherit default protection m em bers or m ethods.

1.20 Packages
I know, this access stuff is a lot to chew and swallow in one setting. It is even harder
if you don’t have a feel for what a package is. Most books I have read on Java really gloss
over packages. M ost are written by people who have worked with the language for m any
years and find packages as natural as object libraries on a linker com m and line. Let m e
try and paint a m ental picture for you about packages.
W hen we covered RM S indexed files in Book O ne, I spent quite a bit of tim e covering
indexed files with m ulti-typed records, even though we didn’t create any files of that type.
I did this for several reasons. The first of which w as that you will encounter them if you
work on OpenVM S long enough. The second reason was to explain why they cam e into
being. Packages are another one of those things w hich m ake absolutely no sense unless
you understand the why behind it.
Had Java never m ade it to the internet, it probably never would have had packages.
They w ould have m ade do with som ething very sim ilar to the object libraries all 3GL
languages have. In an em bedded environm ent which doesn’t connect to the outside world
there is sim ply no reason for their existence. M any of you reading this book will have
spent m uch of your careers writing applications which for all intents and purposes were
stand alone. Yes, they got data from other system s in som e prescribed message or file
form at, perhaps even shared a database, but they didn’t share execution.
Place yourself in a language designer’s shoes for a little w hile. M anagem ent dropped
on your desk a napkin from lunch. On it was scribbled the following requirem ents.
Design a language w hich can run anywhere on the internet, invoke routines from
anywhere on the internet and never have a naming collision. The m anager said “M ake
it work” and walked off.
Im agine for a mom ent, just how m any bank W eb sites w ould have a Java class nam ed
Am ortize on their page. Just how are you going to stop a collision even within one bank
when the A m ortize class created by the car loan group is for 5 years and the hom e loan
group is for 30 years? You could m ake them hard code TCP/IP addresses, but that
probably wouldn’t work either.
Thankfully, the internet already had significant problem s w ith addresses and created
DNS (Dynamic Name Services.) This is what allows you to key w w w .hp.com in your
brow ser w indow and actually get to whatever IP address the site is using today. W ell,
using even that address still wouldn’t help the bank running all of their W eb sites on one
server needing m ultiple Am ortize classes.

1-22

Basics of Java

W hy not just extend the DNS concept though? Don’t actually change the DNS servers,
but use the concept inside of your Java language. In m y sim plistic verbiage, this is what
gave us packages. A way to group classes together so w e w ouldn’t have nam ing collisions
from other locations on the W eb.
Once you have com e to the conclusion that you need packages, how do they function?
Are they just a big pit you toss everything into, like an object library, or should they have
dynam ic functionality? At first blush 3GL developers would say they should be treated
like an object library. This would be a bad thing though. Have you ever worked with C
and tried to get object libraries from 3 different vendors to play nice together? I have. On
the PC platform it really sucked. Besides the header file nam e collisions, each object
library was always com piled with different alignm ent and optim ization param eters. I
stayed up late m any nights getting things like that to play well together.
Hence, cam e the design decision that classes inside of packages could use each other.
Classes from other packages could import functionality from your package. You could
control the level of functionality they were able to im port by a series of access control
keyw ords. In m y hum ble opinion, this is how packages cam e to be. I’m sure that there
is an official story som ew here in the archives of Java docum entation, but this is the story
I like, so it is the one I’m telling.

1.21 Interfaces
Interfaces were Java’s way of adm itting leaving out m ultiple inheritance wasn’t such
a good idea. While you will see interfaces used widely, they should really be called
something like “Napoleonic Rules”. Other than a list of rules and constants for the next
Schm oe to actually code, interfaces buy you nothing. No code can exist in an interface,
just abstract methods and constants.
public interface MyRules {
void sayplease();
}

An interface can “extend” other interfaces, but cannot extend a class. A class uses the
interface by telling the com piler it “im plem ents” the interface. You can “im plem ent” any
num ber of interfaces.
public class MyClass implements MyRules {
public void sayplease() {
......
}
}

The beautiful part about m ultiple inheritance with C++ is you could put m ost of the
implem entation issues in the classes you inherited from . The shiny new class only had to
actually im plem ent method overrides when it needed a m ethod to do som ething different.

Basics of Java

1-23

Im agine, if you will, a pair of interfaces with 15 m ethods each. Im agine you have to
create a class which needs to im plem ent both of those interfaces. The com piler is going
to force you to provide the code for every one of those interfaces. There may very well be
only two that your application will ever use, but som ebody m andated you use those
interfaces, or you needed the constants provided by them . It is a sorry state, but one we
m ust endure when working with Java.

1.22 Threads
I’m going to touch briefly on threads so you have som e exposure to the topic. On the
OpenVM S or any robust platform , I highly advise you avoid threads completely. Threads
are what you get w hen an operating system w asn’t designed to be a robust m ultiprocessing
system from the ground up. OpenVM S was designed from the ground up to be a robust
m ultiprocessing system . Unix and DOS were not. The GUI versions of DOS were task
sw itchers. I have severe doubts about the version of W indows XP Pro I have on one
m achine in this office as well. Those doubts are fostered by giving the m achine the
M icrosoft salute (<CTRL><ALT><DEL>). The button at the bottom reads “Task list” and
when you click it you get a list of im ages not accom panied by process Ids.
W hat is strange is that U nix and the C language started out on a DEC PDP m achine.
I do not know of an OS from D EC for that hardware which did not do m ultiprocessing
correctly (RSTS/E, RSX-11, RT-11). There should have been an inkling, then again, Unix
was originally designed to be a single tasking system which allowed a few users on for
m aintenance. It’s real purpose was to run sw itching software. When you don’t need
m uch, threads work, so does task switching. W hen you need robustness you need an OS
which was designed from the ground up to be m ultiprocessing.
Threads are com pletely different from m ultiprocessing, though people tend to talk
about them as if they were m ultiprocessing. The im ages conjured up with threads tend
to be either cloth or yarn. M any threads woven together making som ething of substance.
Not every thread starts in the sam e place, nor does it contact many of the other threads.
Som e threads are joined to the ends or m iddles of other threads, relying on them for points
of reference in the greater whole.
M ultiprocessing, at least from the way in which you see and use it on O penVM S is
com pletely different. For purposes of visualization, every process starts at the sam e point.
Processes can create as many processes as the user nam e in the U AF will allow. When
you spawn a sub-process, it has its ow n life, but carries w ith it luggage stating it cannot
outlive its parent. If the parent, or creating, process dies spastically OpenVM S knows
about all of the sub-processes it created so it forces them into ritual suicide.
In the very early days of C program m ing there were som e fine m agazines available
for subscription. Magazines like “The C Gazette” and “Program m er’s Journal” to nam e
just two, m ade you proud to be a program m er. Excellent writing, in-depth articles, and
alm ost no hawking of products by the writers. These were the good days. I don’t expect
to ever see them again. One them e which kept com ing up in the articles over the years

1-24

Basics of Java

were tools and techniques for finding and elim inating “dangling threads”. The definition
of a “dangling thread” m ost often offered up was a thread created by a parent thread and
the parent thread no longer existed. Due to the way threads were im plem ented, the OS
had no easy or direct m ethod of killing that thread off. It would sit out there consum ing
resources until it found a way to end itself, or your box becam e so bogged dow n you had
to reboot.
Back in Book One I exposed you to the following comm and:
$ SHOW SYSTEM

If you have an account with OPER priv, or better yet, the privs of God, issuing that
com m and gives you a list of processes on the m achine, no m atter who created them . Most
im portantly, it gives you the PID for each process. If the only thing you wish to find is
associated with an interactive user, you can use:
$ SHOW USERS/FULL/NODE

The /NODE qualifier is only needed if you are on a cluster and wish to restrict the
output to only those users on your current node. Once again, you will get the PID
associated with the process.
Let m e provide you with an actual exam ple of what I’m talking about. In order to do
this I need two term inal sessions. One to issue control com mands from and one to kill off.
Here is the info of m y control session:
$ show term
Terminal: _TNA6:

Device_Type: VT400_Series
Owner: _TNA6:
Username: HUGHES
Remote Port Info: Host: 192.168.0.22 Port: 3106
Input:
Output:

9600
9600

LFfill:
CRfill:

0
0

Width: 132
Page:
32

Terminal Characteristics:
Interactive
Echo
Hostsync
TTsync
Wrap
Scope
Broadcast
No Readsync
No Modem
No Local_echo
No Brdcstmbx
No DMA
No Commsync
Line Editing
No Dialup
No Secure server
No Syspassword
No SIXEL Graphics
Numeric Keypad
ANSI_CRT
Advanced_video
Edit_mode
DEC_CRT3
DEC_CRT4
VMS Style Input

Parity: None

Type_ahead
Lowercase
No Remote
No Form
No Autobaud
No Altypeahd
Insert editing
No Disconnect
Soft Characters
No Regis
DEC_CRT
No DEC_CRT5

No Escape
Tab
Eightbit
Fulldup
Hangup
Set_speed
No Fallback
No Pasthru
Printer port
No Block_mode
DEC_CRT2
No Ansi_Color

It is very im portant to rem em ber your term inal when doing things like this. Those
who don’t rem em ber the terminal they are w orking from when trying this will issue a
STO P/ID on the wrong process and suddenly find they aren’t logged in anym ore. After
logging in as m yself in another session m y system looks as follows:

Basics of Java

1-25

$ show users/full/node
OpenVMS User Processes at 12-JUL-2005 11:43:44.23
Total number of users = 1,
number of processes = 2
Username Process Name
HUGHES
_TNA6:
HUGHES
_TNA7:

PID
000003E7
00000851

Terminal
TNA6:
(Host: 192.168.0.22 Port: 3106)
TNA7:
(Host: 192.168.0.22 Port: 3558)

Keep in m ind the term inal ID for m y control window . This helps me get the correct
PID.
$ set host 0
Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3-1
Username: guest
Password:
*****************************************************
*
*
*
WELCOME.TXT
*
*
*
*
Welcome to the Alpha node LGKL1 run by Logikal
*
*
Solutions.
*
*****************************************************
Last interactive login on Friday, 21-JAN-2005 14:38:08.49
You have 12 new Mail messages.

Your password has expired; you must set a new password to log in

New password:
Verification:
Password found in system dictionary; please choose another string
Please try again or press <CTRL/Y> to abort login
New password:
Verification:
$ show users/full/node
OpenVMS User Processes at 12-JUL-2005 11:46:24.92
Total number of users = 2,
number of processes = 3
Username Process Name
PID
Terminal
GUEST
GUEST
00000856
RTA1:
(1025::HUGHES)
HUGHES
_TNA6:
000003E7
TNA6:
(Host: 192.168.0.22 Port: 3106)
HUGHES
_TNA7:
00000851
TNA7:
(Host: 192.168.0.22 Port: 3558)
$ stop/id=851
$ show users/full/node
OpenVMS User Processes at 12-JUL-2005 11:47:41.66
Total number of users = 1,
number of processes = 1
Username Process Name
HUGHES
_TNA6:

PID
000003E7

Terminal
TNA6:
(Host: 192.168.0.22 Port: 3106)

In order to sim ply create another process for the term inal I used the SET HOST
com m and we talked about in Book O ne. Yes, I could have done a spawn of som e program ,
but the exam ple works well for what we wish to show.

1-26

Basics of Java

After logging in as GUEST, and finding out the password had expired, my system
showed three users. Notice that the GU EST user w as assigned its own PID. Since the
process was using the same term inal as the process w hich created it, a funky RTA
term inal num ber was assigned.
Back in my control session, I stop the PID for the parent process. OpenVM S forced the
GUEST process to com m it ritual suicide when its creating process went away. This is
m ultiprocessing done correctly. It provides for the m ost robust and secure system . You
can do sim ilar things on IBM ’s O S/390 w hich now has som e kind of OZ nam e. They did
m ultiprocessing correctly as w ell.
Please, don’t take just my word for it. Conduct experim ents yourself. Take a look at
the history of a product once called DECThreads. This product/library/package got written
in the later years of DEC when Unix developers wanted to start porting their software to
OpenVM S. It seem s that just about every package used threads in som e m anner or other.
Trying to bend those packages into environm ents which had robust m ultiprocessing
capabilities was a com plete redesign. In response to that need DECThreads got written.
It doesn’t “port” thread software to robust m ultiprocessing. It im plem ents threads under
the protection of a robust m ultiprocessing OS.
The above exam ple is a pretty perfect exam ple for you to try on other platform s. There
used to be a utility on m ost Unix boxes which would basically provide the sam e
functionality as SET HOST 0 does under OpenVM S. This w ould allow you to log in as
som ebody else without killing of your original process. If som ebody did kill off your
original thread, the thread for the new user becam e disconnected from the term inal,
drifting aim lessly in the breeze of the cyber world.
W hen writing Java on OpenVM S, don’t use the thread portion of Java. In later
chapters we will be coding tools w hich w ill let you use LIB$SPAW N(). You are fam iliar
with LIB$SPAW N() from Book One. One thing you probably haven’t done though is log
into another session and use the SHOW USERS/FULL com m and to see what happens
when you go into one of the menu options.
The only piece of the Thread package which you should consider using is the sleep()
m ethod. Java buried this function in that package. Since w e don’t w ant to w rite all of the
code to set this up ourselves, and it is a stand alone feature (Doesn’t require you to use any
other part of the Thread package) it is safe to use. This m ethod will also allow you to catch
an interruption exception like the W AIT statem ent in BASIC.

1.23 Exceptions
W hat
handling.
a block of
sim ilarity

are exceptions you ask? This is a term Java borrowed from C++ for error
On the surface it looks very m uch like the error handling in C++. You enclose
code with a “try” and follow it by a “catch”. That is pretty m uch where the
ends though.

Basics of Java

1-27

Under Java, exceptions are a class. Remember, everything is a class in Java except
the m ost basic of native data types. All exceptions are derived from the Throwable class.
W hen you declare a class m ethod which could potentially throw an exception you m ust
identify the exceptions it throws in the declaration.
Throwable has two sub-classes: Error and Exception. Classes derived from Error
typically have Error as their suffix while classes derived from Exception are given
Exception as a suffix. The Error class is typically used for hard system s type errors such
as running out of m em ory while the Exception class is typically used for things a program
could recover from. There is a lot of docum entation available on-line and usually bundled
with m ost distributions about all of the different exceptions and errors.
Because these are classes and not specific num eric values, exception handling can be
pretty tricky. The list of caught exceptions is processed sequentially when an exception
is thrown. If you derive your own exception from the class IOException, but catch
IOException first in the catch list, that path will always be taken. M ost com pilers today
will flag this as a com pilation error, but older im plem entations m ay not.
The fly in the ointm ent for new developers is the finally clause. This is not the allelse-fails portion of exception handling. The finally clause will be executed for a try block
no m atter how the try block com pletes. This concept is tough for developers com ing from
BASIC to follow. Even if you branch out of a try block with Java’s version of the GOTO
statem ent (continue label, break label or sim ply a return statem ent) the finally block will
be executed. If you have an exception get thrown in your try block, the finally block will
be executed whether the exception is caught or not.
W hat happens if the thrown exception isn’t caught? Java executes the finally clause
for your try block, passes the exception up to the next calling/enclosing block, and repeats
the process of trying to catch the exception. The finally clause is executed for each block
of code the exception bubbles up through un-caught until Java is forced to abend your
process or the exception is finally caught.
All exceptions have the following m ethods available to them since they are all derived
from the Throwable class:
getM essage() to obtain the text of the error m essage
printSatackTrace() to print a stack trace show ing where this occurred
toString() to show the exception nam e along with the getM essage() result
The throws clause on a m ethod definition is m ore than just an ornam ent. Any
exception which is not derived (inherited) from the Error class or the Runtim eException
class m ust be either caught in the m ethod which throws it or be listed in the throws clause
of the m ethod. The com piler isn’t forward looking enough to see if the caller is catching
the exceptions, but it is forward looking enough to enforce this rule within the compilation
of the m ethod. If you throw an exception in your m ethod and don’t catch it, you will
receive an error m essage stating the exception must be listed in the throws clause of the
m ethod.

1-28

Basics of Java

I know, if you don’t com e from an OOP background that last paragraph is a lot to
digest. Error handling, w ith any language, is something programm ers m igrate towards
slowly. Yes, we are all taught in college that we should test our applications with a 4 or
5 year old at the keyboard because they will enter complete garbage. The reality is that
first we m ake it work, and as tim e allows, we m ake it work well. In the old days of BASIC
program m ing when every line had a line num ber and the stack dum p would give you the
com plete inform ation including the line num ber, this w orked well. You coded up your
program , then added error handling at the end as your testing generated stack dum ps.
W hile it was tim e consum ing, it did work.
Purists will state that you need to create your own exception class for any abnorm ality
which could arise, and catch it in your program . Purists usually don’t have to get 40 hours
of work done by tom orrow m orning. The old trick of having your m ethods return
num erical values which your application tests still w orks in Java. M ost developers new
to Java will use try-catch-finally blocks inside of their m ethods, then return a value from
the m ethod indicating success or failure just like we have done with every 3GL since the
dawn of tim e.

1.24 JAVA$CLASSPATH
M ost developers com ing from the lesser platforms will be fam iliar with a sym bol called
“classpath” if they do any Java development on those platform s. Most of the Java
com m ands also add a switch “-classpath” for you to specify the path to look for class, JAR
and ZIP files when Java goes looking for classes to dynam ically load.
Sym bols are som ewhat lim ited in their use. OpenVM S provides an additional logical
for the Java environm ent known as JAVA$CLASSPATH . You can define this logical
anywhere in your LNM$FILE_DEV search list. The first definition found w ill be the
definition used by Java in your process. This logical can be a com m a separated multivalue logical. The Java environm ent will translate as m any iterations as it needs to find
what it seeks. As with all m ulti-pathed logicals, you are responsible for m aking sure what
you want to execute isn’t hidden by an item of the sam e nam e found earlier in the search
path.

1.25 A Little Lecture on Strings and R eferences
Those of you who paid attention to our discussion about references under C++ are
going to bleed pretty profusely when trying to learn Java. W hen you passed a String class
via reference under C++, the called function got to manipulate the actual object. When
you hear about everything being a reference in Java it is quite natural to assum e you are
m anipulating things just like in C++. DON ’T ASSUM E!

Basics of Java

1-29

TestString.java
import java.util.Arrays;
public class TestString
{
public static void main(String[] args)
{
String aString = "abc";
System.out.println("|" + aString + "|");
rightPadString( aString, 8);
System.out.println( "After padding |" + aString + "|");
aString = rightPadStr( aString, 12);
System.out.println( "After second padding |" + aString + "|");
//
//
How do we create a dynamic string of stuff like we did with BASIC?
//
int i = 24;
char c[] = new char[i];
Arrays.fill( c, '*');
String s = new String( c);
System.out.println( "Our dynamic string of characters " + s);
}

// end main method

private static void rightPadString( String s, int i) {
while (s.length() < i)
{
s += " ";
}
// end while loop
System.out.println( "String before returning from pad |" + s + "|");
}
// end rightPadString method
private static String rightPadStr( String s, int i) {
while (s.length() < i)
{
s += " ";
}
// end while loop
System.out.println( "String before returning from pad |" + s + "|");

}

return s;
}
// end rightPadStr method
// end TestString class

$ javac "TestString.java"
$ java "TestString"
|abc|
String before returning from pad |abc
|
After padding |abc|
String before returning from pad |abc
|
After second padding |abc
|
Our dynamic string of characters ************************

It is a tiny little exam ple program , but it provides quite a bit to rant and rave about.
The first highlighted line is a m ethod call which attem pts to pad a string on the right until
it is a designated number of spaces long. Those com ing from C++ and used to how passing
a reference works in that language would attem pt to code this m ethod in exactly this
m anner. The line highlighted below it is how you actually have to code the m ethod.

1-30

Basics of Java

Take a look at the output. W e pass in “abc” and the string created inside of the
m ethod looks as we expect. When we get back to our main m ethod w e see the original
string was not altered. In other words, the reference was passed by value. (It’s OK if you
feel you need a drink at this point.) When we start w orking with the Java Native
Interface (JNI) the definition of “reference” will get even m uddier.
W hy do I bother show ing you how to pad a string? W hen we get to the report portion
of our application you w ill learn that Java was never meant to be a business language.
Java, prior to version 1.5.x didn’t provide any m eans what-so-ever to create a nice
colum nar report. The Num berForm at class gives you back a string without any leading
or trailing spaces. It took Java over a decade to catch up to the 1970's.
M y last little exam ple in this program is how to create an arbitrary string of
characters. I tossed this in because I had just read yet another m issive about how easy
Java m akes strings. They were lam enting about the days of C and having to use sprintf()
to create strings, then overwriting the destination buffer because it was too sm all. Even
with that potential disaster, sprintf() provided a lot m ore functionality than Java. BASIC
provides the best string handling with a distinguished nod to COBOL’s UNSTRING verb.
Creating a right sided histogram of stars to generate a sim ple chart was trivial with the
STRING$() function of BASIC. Getting an arbitrary string of spaces to blank som ething
out was even less effort with SPACE$(). COBOL gave you the key word SPACES and it
did everything for you. Java didn’t bother to look at what cam e before and that is its
biggest downfall.
One thing you should never call Java is “efficient”. It wastes system resources like
dual quad carburetors waste gas. Just take a look at w hat had to be done to create the
string of asterisks. First we had to dynam ically create a character array. Then we had
to use a m ethod of the Arrays class (which is different from the Array class) to fill the
array with our desired character. If we wanted it in string form we had to either use the
toString() m ethod hidden away with our array, or we had to dynam ically obtain yet
another string. Either method left a StringBuffer object laying around waiting for garbage
collection. It doesn’t sound like a lot until you rem em ber that garbage collection generally
runs at “system idle” tim e as defined by the VM im plem entor. Now, think forw ard to a
m ethod w hich has to create hundreds or thousands of these things for output before it
returns. The return would be the first opportunity for the “system idle” process to execute.

1.26 Java Follow U p
Java is a language w hich currently has an ocean of m arketing hype behind it.
Languages which achieve this level of hype usually stay in vogue for 10-15 years. As a
result of these two truths, you, as an O penVM S developer, are going to be forced to write
applications in Java. It won’t be because Java as a language is buying you much over the
3GLs you are already skilled with. There will be a “m anagem ent decision” which will
drive this change.

Basics of Java

1-31

In the world of “m anagem ent decisions”, this one will be a train wreck of biblical
proportions, not because Java is a bad language or has any m ore short com ings than any
other language we have covered so far, but because of the prem ise behind the decision.
M anagement will have seen for quite some tim e in the four color glossy weekly trade
m agazines Java all over the place. They will m ake a not too incorrect assum ption that
Java is now pretty m uch the only language being taught in colleges.
W hat the four color glossies didn’t tell managem ent was the way the language was
being taught. Very few schools teach their students how to sit at an editor and code Java
from scratch. Most of them teach one of the GUI tools. M ost of you reading this will have
been to college and will realize that students tend to sleep through most of the boring
lectures. When you actually have to code the stuff is when you learn it. With the pick &
point GUI tools the students code almost nothing, which m eans they retain close to
nothing.
Think back to the days of your COBOL classes. At least one of the program m ing
assignm ents at the end of each chapter was a program with only a handful of lines that
were different from the program covered in the chapter. Were they really testing your
COBOL m etal? No. But you actually had to key all of that stuff in before compiling. Then
you had to endure the compiler inform ing you of your typos. In the end, you learned
COBOL by repetition.
Java developers using pick and point G UI developm ent tools don’t learn the language,
they learn the tool. It is because of this fact there is a m assive m arket for “m iddleware”
now . Middlew are is the crack cocaine laced nicotine cigarette of today’s IT industry. Once
you let your com pany start using it you have created an addict. The truly shrewd
m iddleware vendors are/will be m aking the license part of the m aintenance agreem ent.
As soon as you stop paying for m aintenance, your license expires. Laugh all you want at
that statem ent, then go read the fine print of your m aintenance contract.
Even with all of these environm ental faults, Java could be a very good language. On
the OpenVM S platform it has som e serious hurdles to cross. There is little to know
support in the current release of Java on OpenVM S for accessing System Services, RTL
(Run Tim e Library) routines or RM S indexed files. There are a few exam ple source files
of how to do this included w ith the release, but there is no com .hp.sys$rtl package nor is
there a com .hp.rm s package that I can find. I have heard that there are m iddlew are
vendors selling products to let Java access RM S files, but haven’t seen any of them .
Expiring license are nothing new. I was once an owner and user of Visual SlickEdit.
As PC editors went it wasn’t bad. Your license never expired, but the installation program
wouldn’t let you install the product after it had aged for a certain num ber of years. I found
this out during a wipe and re-install after a hardware upgrade. Consequently, when I
have to work on the PC platform I now use EditPlus 2 because it doesn’t play that hokey
expiration gam e, I also let everyone I m eet who discusses editors know about that
situation.

1-32

Basics of Java

Java does have the ability to elim inate a lot of other language developm ent. It cannot
elim inate the C language since you m ust use C for the JNI. Java cannot currently be used
safely inside of ACM S servers. Yes, you can use javah to create headers allowing C to call
Java and yes, you could call it from inside of a server. However, if you did that, You would
be lim iting the effectiveness of ACM S.
Given the current state of IT, we as professional developers, will find ourselves writing
m ore and m ore Java applications. Notice the choice of words there. I said applications,
not system s. Java is not a good language for system s developm ent.

1.27 Exercises
1.

W hat are the tw o functional synonym s Java has added to replace the goto statem ent?

2.

W hat is garbage collection?

3.

W hat is m ultiple inheritance?

4.

W hat passes for m ultiple inheritance in Java?

5.

W hat is the definition of a core data type?

6.

How big is the long data type in Java? In C?

7.

If you need a num eric data type which doesn’t neatly fit into a core data type, what
two classes can you use?

8.

Does Java initialize all class m em ber variables? Local variables?

9.

W hat is the default value for a boolean variable?

10. W hat does NAN stand for?
11. How big is a character in Java? W hat type of value is it?
12. W hat is a reference in Java?
13. Does your program actually own the variables you declare in it?
14. Does Java have an include directive?
15. How do you obtain class definitions which exist outside of your source file?
16. W hat is a package?
17. W hat is the format of a package nam e?

Basics of Java

1-33

18. W hat is the nam e of the m ethod Java gives to the destructor?
19. W hat access clause or keyword must be on the destructor m ethod in Java?
20. Can a class have m ore than one constructor?
21. W hat characters represent the conditional operator?
22. W hat is the syntax of the special com m ent recognized by javadoc?
23. W hat is an abstract class?
24. W hat keyword is used in the Java syntax to indicate one class inherits from another
class?
25. W hat does the keyw ord “super” refer to?
26. W hat com m and or utility do you use to com pile a Java source file?
27. W hat is a polymorphic function?
28. In what order must the statem ents appear in your Java source file?
29. W hat are the two groups of modifiers for data types and m ethods?
30. W hat does the native m odifier on a m ethod indicate?
31. W hen is the static section of a class executed? How often is it executed.
32. W hen does the transient m odifier take effect? W hat does it do?
33. W here are m ethods and m em bers declared with the “private” keyword visible?
34. W here are “protected” m ethods and m em bers visible?
35. W hy were packages added to Java?
36. W hat is the fundam ental difference between exceptions in C++ and exceptions in
Java?
37. W hen will the “finally” clause be executed and under what conditions?
38. W hat happens if an exception is not caught in the current class m ethod?
39. If the m ethod you w rite could generate an exception which you don’t catch in that
m ethod, what do you need to do?

1-34

Basics of Java

40. W hat is the purpose of JAVA$CLASSPATH ?

You have been reading an excerpt. Please visit
http://www.theminimumyouneedtoknow.com to find out more about this
book series and how to purchase books by this author.

Chapter 2

Using RTL and SYS Calls
2.1 G oal of This Chapter
This book is going to lay the groundwork for you to create all of the tools you need to
m ake Java a usable language on OpenVM S. While I’m certainly not going to code a
m ethod for each and every SYS$ and RTL function existing on the platform , w e are going
to code a package w hich contains m ethods for m ost of the functions used in prior versions
of our application. We barely dented the surface, but their should be enough for you to
begin learning Java by cutting and pasting to add new m ethods for additional function
calls.
W e will create VM S RTL classes for lib$spawn() and lib$set_logical(). In addition we
w ill c r e a te a V M S D a te c la ss w h ic h w i ll c o n t a in th e m e th o d s fo r
lib$init_date_tim e_context(), lib$free_date_tim e_context(), lib$form at_date_tim e(), and
lib$convert_date_string(). The reason we will be splitting the date stuff out into its own
class is I want the class destructor (finalizer in Java speak) to always clean up the date
tim e context. Due to the nature of lib$do_com m and() never returning, I won’t be showing
you how to call that funcion.
W e won’t be covering calling lib$cvt_dx_dx() in this chapter. The only tim e you would
need it is if you are reading a file created by older BASIC or COBOL program s. W hen we
cover interfacing with RM S Indexed files, we will call it there.
It is m y hope that you find the journey through this chapter worth your while. I think
it will be m uch m ore useful to a seasoned developer than all of the canned 15 line exam ple
snippets you find in other books.

2.2 O rder of D evelopm ent w ith JN I
W hen you w ill be writing Java classes which use the Java Native Interface
developm ent m ust proceed in the follow ing order:






Code the Java class
Create a directory tree if working with packages
Run javah against the class file to create a header file
Code your C/C++ program or m odule
Create a linker options file for the C m odule
Link a shareable image out of your object and options file
Define a logical which points to your shareable im age

After looking at the above list, m ost of you are probably beginning to understand why
m ost books on Java choose to talk about creating generic applets and W eb pages. The
hack at it - try it - hack at it - try it approach works well for Java applets, not requiring
you to think too far ahead. You actually have to do a little bit of design work when using
JN I.