RE: Look Mom - No Application Servers

You have a lot of good points Pete. I think the main reason many shops don't
want to go the Java (or PHP) route is because the introduction of a new
programming language is VERY expensive once all is said and done. When a new
programming language is introduced it is usually because guys like ourselves
found a solution (possibly open source) to get an application out the door
in short order where it would have taken twice to three times the work to do
the same in RPG - so a little time was saved on the front end with
Java/PHP/.NET.

The problem is now that the code needs to be change managed. Let's say for
the sake of argument that there are 5 production iSeries boxes that need the
new Java/PHP code. Let's also say that I have the first version out there
(installed manually) and have started to work on the next version. At this
point change management has to start and the question becomes: 

"Does my CMS package support the change management of Java/PHP?"

"Does my QA group know how to test Java/PHP?"

"Does my CMS package have the ability to do automated
distributions/installs?" 

"When my application breaks how many people need to be involved to debug it?
(i.e. J2EE front end is calling RPG business logic through stored
procedures. Both Java guys are out this week so we can't fix it until
Monday)"

"Do I need to add another conference to enter the picture and educate my
staff differently (i.e. JavaOne vs. RPGWorld.com/COMMON)"

"Do I need to buy/use different toolsets or learn how to install a new set
of plugins for Eclipse and then have my IT support staff take care of those
installs (i.e. Zend's editor or installing, php plugins for a base eclipse
install,or having to go the route of installing plugins for J2EE development
if not using WDSC)

I lived through such a challenge in a medium sized shop (25 or so
programmers). It can get messy/expensive/cumbersome fast when new languages
are introduced.  A shop just needs to make sure it is a well thought out
decision and ensure it fits with their long-term IT strategy and not a short
term "I found it free online" fix.

My $.02,
Aaron Bartell
http://mowyourlawn.com/blog

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Pete Helgren
Sent: Sunday, April 16, 2006 5:18 PM
To: Java Programming on and around the iSeries / AS400
Subject: Re: Look Mom - No Application Servers

When I get the chance, I'll do a little more "educating" of myself on JIT
compilers.  I thought, and stand corrected now, that Java was "slower"
because of the nature of the JVM, and abstraction from the "core" of the O/S
and machine interface. So much to learn....

Sounds like you have had much more experience bringing RPG folks
successfully over to Java than has been my experience.  I certainly enjoy
moving between the RPG/Java/PHP worlds and you probably won't find a bigger
advocate for 21st century skills development in my company, but my
experience has been that making that jump is pretty hard for most RPG
programmers for the variety of reasons that have been debated on this list.

Pain points?  What I meant was that there were still things that cannot be
done in RPG when it comes to equivalents to what may be available in a
language like Java or PHP.  I can see a need for a web services provider for
RPG.  Maybe a messaging provider that was JMS compliant (perhaps there is
such a thing).  As I try stuff in RPG I find that I need something that is
available already in Java.  So I either wrap a Java class or just write it
in Java.  I am OK with that, but some folks would be stuck, so that can
cause some "pain".

And, when I talk about these thing I guess I am reflecting on what would
allow an RPG programmer to stay in the "comfort zone" but still be able to
write applications that are equivalent to enterprise web applications in the
Java world.  Why would that even be necessary, especially when so many open
source and commercial applications already exist that fill that need?  Well,
the Java/PHP worlds clearly overlap on tools and API's.  There are PHP
programmers who want to write only in PHP and thus create functional analogs
to existing Java tools and apps.  There are Java programmers who only want
to write in Java and thus will write Java tools and apps even though they
exist in the PHP, C or other programming worlds.  You can see that
duplication in C++, Perl and in dozens of other languages. I don't see why
RPG should be excluded from that "club".  If there are folks who want to
build RPG tools and apps, even though those tools and applications may exist
in another language, then more power to them.  It is not inconsistent with
other languages in the marketplace.

Me, I would rather make the "small investment" of learning something new,
but not everyone has the inclination, the time or the freedom.

Pete


Joe Pluta wrote:

>>From: Pete Helgren
>>
>>I wasn't aware that "JSPs eventually compile down to machine code."  I 
>>assumed that JSP compiled to servlets which ran in a JVM which meant 
>>it was still "interpreted" to some extent.
>>    
>>
>
>Do a little Googling on "Hot Spot Compiler" or "JIT Compiler".  It's 
>pretty cool stuff, and a great reason why certain logic, especially 
>stable code that gets used over and over (I call these static solution 
>sets), really are well suited for Java.
>
>
>  
>
>>Agreed that Java has many more tools and ready made API's.  But, I 
>>wouldn't use that as the sole rationale for not developing RPG 
>>equivalents.
>>    
>>
>
>It seems easier to learn to use a couple of APIs rather than spend the 
>money to reinvent the wheel.  That's almost like rewriting OS/400 
>system APIs because the API interface is complex.
>
>
>  
>
>>There are some "pain points" that I think could be addressed in RPG 
>>that would encourage more application modernization and would give RPG 
>>programmers a more comfortable environment to grow from.
>>    
>>
>
>I'm not sure what this paragraph means.  Could you give me an example?
>
>
>  
>
>>Not everyone enjoys jumping into Java, PHP, and other non-RPG web 
>>technologies.  The success of the System i platform, is, to some 
>>extent, still tied to RPG programmers so I'll continue to pursue tools 
>>that pull them into the 21st century.
>>    
>>
>
>The success of the IBM midrange is completely tied to its ability to 
>integrate many different technologies.  RPG is one, and happens to be 
>my favorite language.  At the same time, by making a small investment 
>in learning a simple Java framework, you can make your RPG programmers 
>much more productive.  They never have to worry about the UI at all; 
>instead, they just write business logic.
>
>Really, there are very few situations anymore where you can justify an 
>RPG-CGI approach.  A small one- or two-person shop with zero training 
>budget is probably one such place; few others come to mind.  If your IT 
>shop doesn't have the skill set to learn the 1000 or lines of Java 
>required to create a web application environment, I can't see how you 
>can possibly have the skill set to rewrite something like SOAP in RPG.  
>It's just not possible.
>
>Joe
>
>  
>
--
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.