|
> 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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.