Re: Life in general

What you really need for .. systems development is something other than
Java
... Java is really no stronger than VBasic .. and has no data base support
either ... but I guess you like to just play with toys... not real
programming ..
--------

<laughing>

Don't beat around the bush, Gene!  Tell me how you REALLY feel!

Okay, this is a decent little subject for a quick recap.  While I know most
of the readers of this forum are committed to Java, it probably doesn't
hurt to review some of the strengths of Java versus other languages.

First, let me indulge my own ego for a moment to point out my
qualifications.  I've been programming for over 20 years.  In that time, my
primary focus has been distributed systems for IBM midrange computers,
starting with a S/3 model 15D, going on to the Series/1, and then the S/3x
and AS/400.  I used RPG and COBOL, which should pretty much fit your
definition of a "real" language, Gene.  At the same time, I was was
developing code for microcomputers (which is what we called PCs before
there were PCs).  I've written in assembly, Pascal, C, C++, BASIC, dBase
and Java, on chips ranging from 8080 and Z-80 to Pentiums.  I'm one of the
few people I know who has written an operating system that is still in use
today (it's on a device called Access Telecom, which is a multi-protocol
communications controller).  I developed the first distributed national
credit card system on a System/38 for Navistar, and I was the architect of
the first commercial client/server ERP application, the Assistant products
for BPCS.

Okay, that's enough horn-tooting.  If that's not enough to establish my
credentials, Gene, then I don't know what else to tell you.

In all my experience, I have never seen a better transaction processing
machine than the IBM midrange, and the AS/400 is simply the latest
exceptional entry in that line.  Unfortunately, no matter how hard I've
tried, I have been unable to create a commercially viable graphical
client/server package for the S/3x-AS/400, for two reasons: until fairly
recently IBM insisted on speaking SNA in a TCP/IP world, and there was no
standard graphical client we could write to.

IBM handled the communications issue by pretty much shifting their entire
focus to TCP/IP, to where the AS/400 is (according to those who know way
more about these things than I!) one of the most full-featured TCP/IP hosts
currently available.  BTW, if anybody knows area where IBM comes up short
in TCP/IP, I'd like to know.  One of my pet projects is to see if it's
possible to develop an entire network using only an AS/400 and Linux boxes
as workstations.

As to the graphics problem, well, there have been efforts along the way
which simply haven't panned out, and every one has the exact same problem:
you have to either tightly control the workstation hardware and software,
or you have to write some sort of generic graphics.  At SSA, we attempted
to control the hardware environment by telling our clients exactly what
hardware they needed (and since we wre using OS/2 as the operating system,
they were pretty hefty clients), but we still had problems.  Our Japanese
clients needed special double-byte capable terminal, which ranan operating
system called JOS/2 (Japanese OS/2).  The subtle (and not-so-subtle!)
differences between platforms made it necessary to have different versions
of the code.  Then we had to write an NT version, because OS/2 lost the
operating system war.  And of course, there were different versions for
each release of the various operating systems.

Well, I began the job of encapsulating the logic in the Assistant products
and isolating it from the presentation.  While I didn't know it at the
time, I was moving towards the MVC architecture (Model/View/Controller).
By the time I left SSA, there was a product which made generic graphics
calls to an underlying grahics engine.  The engine was ported from machine
to machine.  In effect, we had developed our own virtual machine, although
I was nowhere near bright enough to realize it at the time.

For the next several years, I concentrated on the Y2K issue and developed a
highly successful Y2K remediation product.  But I kept dallying with
graphics and of course, the newly emerging World Wide Web.  Something told
me the WWW would be somethng a little more important than personal home
pages and cybersex sites.  And then I started working with Java, and I
realized that this was the graphical front end the AS/400 had been waiting
for.  Why?  For a number of reasons:

1. Java is truly object-oriented, rather than object-based.  You can easily
extend the language, and its powerful object-oriented features make code
development quick and productive.  Proper use of polymorphism, inheritance
and encapsulation are way too longwinded to go into even in this rambling
post, but it means that properly designed system objects can be used very
easily by application programmers and shared throughout the system.

2. Java is platform independent.  Completely and totally.  If you write
100% Pure Java code, you can be assured that it will run on any JVM
anywhere.  This includes the graphics, which is to me one of the single
most impressive programming feats of the 90's.

3. Java completely separates presentation from data.  Every widget in the
Swing toolbox uses the MVC architecture, which means it is easy to change
your presentation without touching your logic.  And if you follow that
design with your own classes, it's amazing how flexible and powerful your
designs become.  As the ultimate expression of this philosophy, one line of
Java code can change an entire application from looking like a Windows
application to looking like a Macintosh application.

4. Java supports alternate input devices from the ground up.  This is a
sign of the "good human nature" aspect of Sun Microsystems.  Java is
designed to support any sort of special input device, from breath
controllers for the paralyzed to Braille controllers for the blind.  Sun
didn't have to do this, but they have.  I've seen no other major
corporation make this depth of a commitment.

5. Sun is committed to keeping backwards compatibility, which means that in
most cases, your program object will run on any JVM, now or in the future.
This single ability makes it a million times easier to support distributed
software management; you can upgrade your users' JVM for speed and bug
fixes, but you don't have to change their client software until it's
convenient.

6. Java has built-in support for JDBC, which supports any ODBC capable
database.  At the same time, more and more vendors are writing
JDBC-specific drivers to up the performance.  And if that's not enough,
IBM's Java Toolbox for the AS/400 provides sophisticated record-level
access support (which I've encapsulated into some pretty simple classes
that make it easy for RPG programmers to access AS/400 data).

I could of course go on and on (as many who know me can attest to).  I've
written tens of thousands of lines of Java code, and I'm quite comfortable
that I will write many tens of thousands more.  I've released four
packages, and am about to release four more, all of which provide robust,
flexible access to AS/400 resources for graphical workstations.  I write
the code and test it on a Wintel workstation, then copy the code directly
to the AS/400 for system testing.  That simply can't be done with any other
language.

Anyway, I thought it would be a nice end-of-the-year thing to recap where
we are, and why I personally think that Java, and especially Java/400, may
well be the most significant advance in distributed processing, especially
for IBM midranges, of the 20th century.

Joe Pluta
www.java400.net


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---