Object Oriented Programming, jWPS and OS/2:
A Quick Overview
Introduction. What is OOP?
OOP, as object-oriented programming is known, is a way of organizing code that makes
it more robust and modular.
The basics are:
- Inheritability. The ability of an object to be specialized to a new object.
The new object retains all of the attributes and behaviors of the old, but may
add some of its own. a vehicle can be specialized to a car or a
motorcycle. All vehicles have wheels, but not all have doors.
- Encapsulation. Being able to treat related things as a unit.
For example, having the color of a car as part of the car's data. This
permits the car to "know" something about itself. This permits the logic
of the system and how it is managed to be distributed to the place where it is needed.
- Abstraction. Extracting from a real world thing (noun) the essential characteristics.
These include attributes (adjectives), included other objects and behavior (verbs).
So a car has a number of doors (attributes), the doors themselves (included objects)
and you can drive it (behavior). This process is dependent upon what we want to do with the objects.
Setting up a system for car dealership has different requirements for setting up the state's
Dept. of Motor Vehicles, so even though they both have a car object, there will be few similarities.
Getting the objects right is the real trick in an OO system.
As the saying goes, the first 90% of any project is design and the second 90% is implementation.
Many computer languages and organizational systems have some of these.
None of these concepts are deep or hard (although that fact seems to be lost in most
Computer Science discussions of OO). It should be stressed that Simula-67 (as in 1967)
was the first bona fide OO programming language, so none of this is new.
However, in the last 10 years it has become very clear that OO methods are the most
flexible and ultimately maintainable. There would have to be a very compelling reason not to
make a large-scale computer system using anything other than OO methods. There is one
great practical attraction of OO design: Future-proofing.
Coming off the starting blocks, most paradigms can yield a system that is of equivalent functionality
to an OO system. Supply it with an attractive user interface and you won't know the difference.
But the OO systems are more flexible. If a new type of vehicle is invented in a few years,
extending an OO system is pretty straightforward. Often it has been found that an older system is
too inflexible to be extended or is of such complexity that it cannot be maintained.
In such cases a complete rewrite from the ground up is the only way to proceed.
For critical systems this is painful at best, the canonical example being the
anguishing rewrite of the national air traffic control system.
The big revolution in the last decade has been the move to object oriented (OO) systems.
In a nutshell, the OO prardigm is now the preferred way for large-scale application design.
OS/2 and OOP
OS/2 is not an OO operating system, regardless of what people say. A common confusion is to
assume that any program with lots of icons and such is object-oriented. Nope. This is not
helped by a lot of vendors who, trying to cash in on OO hype, purposely confuse the issue. OS/2 has
a graphical user interface, the Presentation Manager (PM). This controls windows, list boxes
and the other graphical goodies we've come to expect. But PM is just these and little more.
You can use these in an OO application but they are independent of it.
The major earth-shaking innovation through is in the Workplace Shell, WPS, which is an
OO system that runs under OS/2 and is the heart of the OS's GUI. This is very OO
and robust. The technology that enables this is a very general framework for objects
called SOM (System Object Model). This is a truly grand idea in which objects can be
created in any supported language (C, C++, Smalltalk and others) and then re-used
seamlessly. So your OO application can use objects that are written in some other
language. What's more these objects needn't even be on the same system if you are
using the successor to SOM, DSOM (Distributed SOM).
The WPS is also designed to be extensible. You may write your own version of a class and
replace it system-wide. Inheritance allows these changes to porpagate throughout the system.
In this way it is possible to simply upgrade the functionality of
the system without redesigning it. It has been shown time and again to be a very far-sighted
and robust paradigm.
Java, jWPS and OS/2
So where does jWPS fit into this and why should you be interested in it?
A practical coding issue is that the API for working with objects is pretty
nasty and has a steep learning curve. Part of this is that the syntax tends
to be ad hoc, with little rhyme or reason to it. Interacting with WPS objects
programmatically is hard to do if you are not writing an object. On top of this
IBM has quit actively supporting OS/2. The development tools for it are now being
privately maintained and it is becoming harder to get these to function with each
other. New technologies are not being deployed to OS/2 much at all. The usual
sequence of events is some developer who comes home after his or her day job
and decides to finally port some tool they have become familiar with. This bodes ill.
Java is a high-level object-oriented programming language. It supports
useful libraries and has great functionality. Many large-scale industrial systems now run
under Java and it has been shown to be a robust choice for system-design. Support under
OS/2 has been good and a lot of the first JVMs under OS/2 set the bar for performance.
Java is at the cutting edge. Formerly C/C++ was where newer technologies
would emerge, then be ported to other languages. Now Java is the chief engine for this.
Java is platform independent, so that one may write an application (including graphical
ones) and simply have them function on unrelated hardware. This is good. Since Microsoft
is obviously uninterested in supporting legacy code or allowing non-MS operating systems
to even run its programs, this has given Java a powerful boost.
So now we get to the basic question of what jWPS is. in order to access native objects
under OS/2, special code (using the JNI, the Java Native Interface) had to be implemented.
This violates the portability dictum of Java, since obviously some OS like unix has no concept
of the WPS so attempting to run jWPS off of OS/2 won't work. That's not the point. I wanted to
- give a simple OO system for interacting with the WPS,
- make a development tool to allow people to work with OS/2 who would find learning the WPS API
too hard,
- make newer Java technologies available and viable on my favorite OS,
- have a good alternative to REXX, the much beloved scripting language of OS/2
I think I have done this, in large measure.
What you can't do with jWPS
The way it works is that any existing WPS classes can be accessed and pretty much everything you
want to do with one you can. You cannot write a WPS extension in jWPS. This is because you need
a programming language that can generate dynamic link library (DLL), which is not the case under Java.
There are potential workarounds for this, but none up to this point have really impressed me as being
a good general solution. You also cannot access PM or the low-level control program API (so no
device drivers).