RE: FW: Java Vs RPG on iSeries

> From: Blair Wyman
>
> > Java does NOT play well in that [traditional ERP] space yet.
>
> Consider one highly successful counterexample -- Intentia -- whose iSeries
> embodiment rules the performance roost.  While Intentia is obviously a far
> cry from the "roll-your-own" type of Java that a small shop might write,
> you must admit they *are* playing in the ERP space with Java (and very
> well, indeed!)

And they're not the only ones, Blair.  I agree that there are some players
there.  At the same time, I don't know what their performance is like, nor
whether it can be customized easily.  I just don't know enough to make a
fair assessment.  But your point about it not being a "roll-your-own" is
crucial.  Can a reasonably bright person with intermediate-level Java skills
get in and modify the code?  If so, and if the performance is acceptable,
then we may be seeing the dawn of the Java age for business applications.

Of course, that leaves out one huge issue - the giant reservoir of existing
RPG talent out there - the ones who actually UNDERSTAND business
applications and who can design and develop business application that meet
end user needs.  While Intentia might have a bunch of bright young Java
engineers who also understand application programming, currently that
particular combination of skills is rare.  Whereas the number of RPG
programmers who understand general ledgers or allocations or promotions and
deals is still pretty large.  How do we take advantage of - and at the same
time, provide for - those folks?


> > So I think we can agree that while SPECjbb2000 numbers are impressive,
> they
> > don't make much difference to the majority of iSeries customers.  Maybe
> I'm
> > wrong - if so, I'm sure you'll tell me so <smile>.
>
> Joe, you're wrong.  :-)
>
> I believe that outstanding Java performance is a key factor helping to
> ensure the iSeries has *any* future, at all.

Point received and acknowledged.


> > While Java makes us think in parallel ways, what difference does that
> make
> > to someone posting their general ledger? [snip]  These "meat and potato"
> > applications are the ones that have pretty much built the midrange
> market,
> > and are the ones that seem to get shunted aside by the newer
> technologies.
>
> If customers choose to dedicate their entire box to meat and taters, in
> perpetuity, I guess Java might not make much direct difference to them
> (except as noted above).
>
> However, if the next release of that meat and taters box can also readily
> and efficiently do asparagus (B2B procurement),  a nice salad (CRM), and
> some apple pie (web-serving) -- in "parallel" harmony and without buying a
> bunch of new silverware and dishes -- the restaurant may make the Fodor's
> Guide after all.

And Blair, this is where we absolutely and most assuredly agree.  Java as an
integral part of the overall iSeries technology package is absolutely
crucial!  C'mon, you KNOW I've been saying just that for years!  However,
why does it have to be *instead of* RPG?  Why can't it be *in conjunction
with* RPG?  If the RPG folks widen their horizons to embrace Java and the
web, why can't the Java folks embrace legacy systems?  Recognize that the
millions of lines of "meat and potatoes" code written over the decades have
great value, and the programmers that maintain it are valuable assets in
their own right, and then you have a vision for the future that effectively
takes advantage of ALL of our strengths.

Remember, not every programmer will "get" OO.  And this isn't like a
programmer who refuses to move from RPG II to RPG III or IV; I think you and
I agree that OO programming is a paradigm shift that not every programmer
will make cleanly.  So why not allow business logic, especially the meat and
potatoes kind, to be written in RPG and simply wrapper it in object
interfaces?  This, it seems to me, would not only leverage existing code,
but also allow the really neat stuff to have more of the OO resources it
deserves.

Java tends to pooh-pooh legacy systems; I just wrote an article about that
on MCMagOnline.  The new JDO technology insists on building your database
from scratch once you define your objects - why couldn't they have added
syntax to allow the use of existing legacy databases (not to mention that
it's ridiculous from a system maintenance standpoint)?  It's because Java
designers tend to deny the existing of the vast base of perfectly working
legacy code - code that ain't broke, so doesn't need to be fixed.

So - let's move on from here.  Let's figure out a way to combine object
technology with legacy systems.  Let's design an XML syntax tht defines a
legacy program so that it can be incorporated into an object interface.
Let's continue to allow RPG programmers to do what they do so well - define
flexible, easy to modify business rules - while working towards new
solutions that incorporate new tools.

I'm telling you, if the Java community were half as willing to embrace
legacy systems as old legacy dinosaurs like me are willing to embrace the
new technologies - if you were to meet us even a quarter of the way, much
less half way - then we would see a wonderful, exciting transition period, a
sort of Renaissance of the platform, as we learned to make the new
technologies work even for the meat and potatoes problems.

Joe