The Minimum You Need To Know About Java On OpenVMS
The Minimum You Need To Know About Java On OpenVMS
By Roland Hughes
Logikal Solutions
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 .
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.
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
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
Introduction
I.1 W hy Java?
Thats a very good question. Its a question Ive asked m yself every tim e Ive 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 Im about to w rite an entire book on areas of the language not norm ally
covered, that opening paragraph probably shocks you. Sadly, its 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 werent on the W eb you wouldnt 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 ouldnt 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 couldnt 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 ouldnt 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. Youve always had a cluster to work
with. Youve designed system s to use ACM S servers on every node in the cluster,
consequently, youve never had to deal with load balancing because QTI did it for you.
Youve used RDB for your database because it was cluster aware. With DTM wrapping
your transactions in its protective cloak, youve 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 dont 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 dont counter attack, youve 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 wouldnt 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 werent 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 didnt get a response
within a reasonable am ount of time, they logged into a different vendors 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 arent capable of this.
I-4
Introduction
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 ECOs 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 FTPed 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 ([email protected]).
inflating: DEC-AXPVMS-JAVA142-V0104-24P2-1.PCSI
$ product install *
The following product has been selected:
DEC AXPVMS JAVA142 V1.4-24P2
Layered Product
I-6
Introduction
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.
Layered 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-8
Introduction
Chapter 1
Basics of Java
1.1 A Little Bit of H istory and Concept
Dont worry, Im 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 Im 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, Im
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. (Im still trying to figure out how I got talked into
writing this book. It sure wasnt the publisher, because Im 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 wasnt 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 (dont 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,
thats 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 dont 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 As are
probably already using the once planned em bedded Java. I just dont 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 Ive 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 dont 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. Thats 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. Thats okay. Im not the only C++ developer Ive m et
who has the exact sam e feeling. Ive 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 couldnt live without it. Lets 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 couldnt
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 dont bother learning it. The reason I suggest that,
and the reason I dont 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 couldnt 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 dont 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 isnt 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 its 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 wont go aw ay. It is
also the point w hich leads m e to the opinion about a bunch of developers that couldnt
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
dont 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 Ill
never really understand.
1-4
Basics of Java
Dont 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 dont want to give you
a contrived exam ple, and we arent 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 dont 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 doesnt 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, its okay. There is a reason I
didnt talk m uch about interfaces when we discussed C++ in the last book. I didnt 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 cant 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
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
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
wont 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 dont. 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 wont go into the ins and outs of Unicode. Those
of you wanting to know m ore about Unicode can visit http://www.unicode.org.
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 cant 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
Basics of Java
1-9
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 dont 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 wont 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 wont 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 doesnt 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.
Basics of Java
1-11
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. Ive yet to find a place where it didnt 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.
==
!=
?:
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.
Description
Not
Boolean AN D
XOR (Exclusive OR)
Boolean OR
Conditional AND
Conditional OR
Precedence
1
7
8
9
10
11
These boolean operators dont 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.
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 dont find this in many
languages. The reason for its existence is that Java doesnt 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-14
Basics of Java
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 wont 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.
Dont shake your head or laugh. Ive seen it done. Upon rare occasion Ive 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 dont 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 didnt 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);
}
}
TestScope.java
public class TestScope {
public static void main(String args[]) {
DummyClass h = new DummyClass();
h.printBoth();
}
}
$ javac DummyClass.java
$ javac -classpath [] TestScope.java
$ java "TestScope"
local x is 22
class member x is 7
Adm ittedly we havent 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 didnt 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 dont 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 asnt 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-18
Basics of Java
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
theCount--;
// end finalize method
static { theCount = 0; }
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, didnt need this. Most of
the tim e you wont. By the tim e you do need it, you wont rem em ber how to do it. Javas
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
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 Javas 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 doesnt 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 havent 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 dont 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 didnt 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 doesnt 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 didnt share execution.
Place yourself in a language designers 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 wouldnt 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 wouldnt 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? Dont 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 ouldnt 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. Im 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 Im telling.
1.21 Interfaces
Interfaces were Javas way of adm itting leaving out m ultiple inheritance wasnt 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
Im 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 asnt 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. Its real purpose was to run sw itching software. When you dont 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 ers 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 dont 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 Im 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 dont 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 arent 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, dont 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 doesnt 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, dont 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 havent 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 dont w ant to w rite all of the
code to set this up ourselves, and it is a stand alone feature (Doesnt 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 Javas 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 isnt 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 isnt 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 dont 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 dont 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 dont 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 isnt hidden by an item of the sam e nam e found earlier in the search
path.
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);
}
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. (Its 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 didnt 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 COBOLs 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 didnt 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 doesnt 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.
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 didnt 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 dont 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 todays 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 havent seen any of them .
Expiring license are nothing new. I was once an owner and user of Visual SlickEdit.
As PC editors went it wasnt bad. Your license never expired, but the installation program
wouldnt 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 doesnt 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.
3.
4.
5.
6.
7.
If you need a num eric data type which doesnt neatly fit into a core data type, what
two classes can you use?
8.
9.
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 dont catch in that
m ethod, what do you need to do?
1-34
Basics of Java
Chapter 2
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.