RE: Strategic Java Usage -- JAVA400-L

Paul,

Phew, good reading though!

Cheers
Colin.W

-----Original Message-----
From: Paul Holm [mailto:pholm@xxxxxxxxxxxxxxxxx] 
Sent: 16 March 2004 07:05
To: java400-l@xxxxxxxxxxxx
Cc: Nate Levis; Wes King; Beth Hoffman; Jon Chester; Phil Coulthard; Nikki
(Nicole) Jensen; Tyler Holm; Jon Paris
Subject: Strategic Java Usage



Joe/Dieter and All,

I've enjoyed reading the recent posting on Java/RPG/Performance topics.... I
wanted to share my thoughts and experiences....  My passion is design and
architecutre but being a former IBM "blue zoo" employee..... I still bleed
blue....  My thoughts on the RPG versus Java and SQL discussions....

#1  Object Orientation (OO)

In a nutshell, OO is all about productivity.  OO promises the type of
productivity gains that the advent of interchangeable parts brought to the
industrial revolution.  OO and related design patterns allow the development
of software that can be reused from project to project while project
specific details can be handled by overriding the base behavior.  RPG and
other procedural languages simply don't offer productivity and flexibility
to this level, Java does  (I'm actually a recovering Smalltalk guy which
remains the most powerful language I've seen) .  The problem for most AS/400
shops is that they don't have skilled OO developers.  Most Java developers
that think they know OO really don't and to gain that skill and experience
is non-trivial, expensive, and time consuming.  However, the upside in
potential productivity gains is enormous; Java components can be developed
that "automate" the majority of software development tasks in a generic
fashion yet allow easy customization.
        To provide an example, the following link uses a completely generic
Java based component to deliver the functionality.
http://www.planetjavainc.com/wow60/runApp?id=298  (click on employees and
departments on the left hand side)

  Some of the generic services are:
.       Based on the requirements, display in a "subfile or paged" manner a
set of
fields from a Database.
.       Allow editing of the Database record information.
.       Allow "inserts" of new Database records.
.       Paging support so if there are too many records to display, a "next
and
previous" link are shown.
*     Many additional common software services

In the referenced example, the Java component to display a list of employees
and departments is exactly the same.  This means that any requirement to
select, display, edit, delete database records can be generically handled
via a single component thus saving huge amount of redundant programming. RPG
simply cannot accomplish this.  Analized deeeply, most software development
is the same behavior with differnt databases,  develop a framework that
allows generic treatment of these common tasks and we'd have it made.  The
challenge for AS400 programming shops is getting the skill and experience to
develop their reusabable component infrastructure.  Discussing this very
problem, a knowledgeable OO co-worker told me, "The problem with this OO
stuff, is that people don't even realize how powerful it is until they've
worked with it for 2 or 3 years."  The light at the end of the tunnel is
that components and frameworks are emerging that lessens the need for the
new Java programmer to understand OO design.

#2  Platform independence   (Portability)

The benefit here is that Java can run on any platform and with JDBC against
any database including SQL Server, DB2, AS400, Oracle, etc.  This capability
is often touted so I won't labor the point.  The following link is the same
exact application however it is going against DB2 on an AS400 whereas the
previous link uses DB2 on a Windows 2000 machine.
http://www.planetjavainc.com/wow60/runApp?id=299    The Java component is
exactly the same regardless of the Database!  People often argue that this
portability comes at the cost of not taking advantages of unique platform
capabilities; the truth is that platform optimization can still take place
at the lowest common denominator, which is the operating system and SQL
engine.  For example, Java is portable however Rochester and others have
written there own JVM optimized to their specific platform.  Same with SQL,
when you run a "generic" sql statement, it is a specific Database
implementation that actually executes the statement under the covers.  AS400
folks have been working for years to optimize SQL/JDBC performance as
demonstrated with AS400 unique "system wide statement caching".  V5R2 offers
a new and improved SQL optimizer.  This platform independence is actually
based on an OO design called "interfaces" which provide developers with the
capability to supply their own implementations of a needed API.  (Example:
Oracle implements their JDBC driver optimized to their DB while Rochester
produces the DB2 AS400 driver; same interface but completely different
implementations)  Same concept was used when the AS400 moved from CISC to
RISC.  OS400 was written against the MI or TIMI, you write to an interface
not an actual class then you can swap the implantation with no code changes
from the folks calling your API.  Another advantage that can be gained lies
with SQL and it's every increasing power.  Most shops that I work with
totally underestimate the power of SQL.  Its wrap in the past was that it
was slow.   This was true and today it still maybe slower than standard RPG
however it has capabilities that can be coded in a single statement that
would require significantly more effort in other technologies.   This
following link does a nice job of spelling out some of these points:
http://www.midrangeserver.com/fhg/fhg011404-story01.html Obviously RPG can
use SQL so this benefit is not exclusive to Java.

Other related random thoughts and experiences:

*  For reasons not 100% clear to me.. the AS/400 Java performance seems to
stink.  I've had and helped 3 clients move their apps to Windows and see the
performance improve dramatically.  My understanding of why is:  a)  The
AS400 JVM goes through an extra step of "byte code verification"  for
security reasons   b)  in terms of processor speed and RAM, Java is very
speed and RAM hungry,  I've watched while a "desktop Windows" running at 3
GHZ with 2GB of RAM runs circles around a decent size AS400.  Rochester,
better circle the wagons here..  Bad story and I know you are working on
it..
.       Java has industry wide adoption and related development.  This means
that
you can go out to www.almostWhereEverYouWant.org and find help, source code,
and products related to Java.  RPG can't compete at this scope.
.       Skills:  Not many college students coming out with RPG... Java of
course.
At current levels, most of us AS400 bigots will be golfing in Florida within
the next several years.  If you are a manager/CTO.  you care about this plus
you go with what you know which sadly becomes less and less AS/400.  We have
all battled with Big Blue marketing machine but it has turned its check at
AS/400 specific marketing and investment.
.     Rochester is investiging in Java/WebSphere and SQL not DDS and base
RPG.  Where cheap, they incorporate native support in DDS and RPG...  Makes
sense why Query/400 is dying compared to SQL?  RPG is not getting
significant investment...  IBM says, how can we reduce costs..  Deliver
software for all machines from the same code base....

My advice:

I have many additional thoughts and experiences but people including myself
have very short attention spans so I'll stop at this point:

a)      I'll share my experiences and thoughts in future writings if anyone
cares
b)      Rochester:  Make this stuff easier for the beginner.. Don't make
them
struggle for hours to figure out their CLASSPath... Oh. is that case
sensitive?  Should I have written that on the command line or put it in my
.profile file?
c)      Don't underestimate SQL.   It can do a lot at a lot faster rate than
most
people know.
d)      Java is powerful but has a learning curve.  Once you master it..
Look
out.. Almost like a pilot figuring out a F18 versus the Cessna 152 that they
are used to.  It takes longer but the potential is light years apart.  Want
to engage in a dog fight?
e)      Use Java and SQL until you find that it doesn't perform well enough.
When you hit that consider AS400 program calls to RPG.   RPG has been
optimized for 20+ years while Java is still pretty new.   Implement business
rules as close to the Database as you can.  The advantage is that your
business rules are enforced regardless of the interface.. SQL, JDBC, DFU,
RPG, ODBC, etc.  They all drive via the Database.


System.exit(1);  // :^)



Paul Holm
Senior Web Architect
PlanetJ Corp.
Phone: 760-432-0600, Cell: 760-415-8830
WOW, Web Applications In Under 5 Minutes http://www.gotWebData.net

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx]On Behalf Of
java400-l-request@xxxxxxxxxxxx
Sent: Monday, March 15, 2004 10:00 AM
To: java400-l@xxxxxxxxxxxx
Subject: JAVA400-L Digest, Vol 2, Issue 95



_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.


This e-mail has been sent by a company of Bertram Group Ltd, whose registered 
office is The Nest, Rosary Road Norwich NR1 1TF. 
This message, and any attachments, are intended solely for the addressee and 
may contain privileged or confidential information.  If you are not the 
intended recipient, any disclosure, copying, distribution or any action taken 
or omitted to be taken in reliance on it, is prohibited and may be unlawful.  
If you believe that you have received this email in error, please contact the 
sender immediately. Opinions, conclusions and statements of intent in this 
e-mail are those of the sender and will not bind a Bertram Group Ltd company 
unless confirmed in writing by a director independently of this message. 
Although we have taken steps to ensure that this email and any attachments are 
free from any virus, we advise that in keeping with good computing practice the 
recipient should ensure they are actually virus free.