Re: A Dialogue -- JAVA400-L

Kelly Cookson wrote:

Thorbjørn Ravn Andersen:

A major reason for Java being hard to use is the enormous size of the runtime library, which
just grows and grows and grows.

We may be in a somewhat unique situation, having been an iSeries COBOL shop for many years, but the three main obstacles to our shop adopting Java are:

(1) An OO hurdle. None of our most senior programmers are OO programmers. They have coded mainly in structured COBOL their entire careers. Our new hires generally have a semester of Java from their academic programs, and some of the intermediate programmers like myself have been using OO in PeeopleCode development. But our managers are not ready to adopt a language that makes our most senior programmers novices in the language and our most junior programmers the experts in the language.

Kelly, there are many levels of OO programming similar to marshal arts where you have white belts all the way up to 5th degree blackbelts. It can take a few years to really "get there" but when you do, you realize the incredible productivity compared to structured programming. Ways to reduce this learning curve are:

a. Use of OO frameworks allows you to leverage OO benefits without having to do it all yourself.
b. Utilize a experience consultant/mentor to help your staff learn.

(2) An API hurdle. The J2EE APIs are numerous and often complex. This is a good thing in terms of making Java powerful. And developers don't need to know all the APIs to make good use of Java.. But, to a shop of Java novices (one semester or less), knowing which J2EE APIs to use in different situations and how to use them effectively is daunting. This may arguably be more an issue of perception than training. But a perceptual issue is a real issue when it comes to management decisions.

APIs are numerous but there purpose is to ease your workload because they provide a lot of functionality that you would have to write yourself. It is similar to our AS400 CL commands. How many CL commands are there and which ones should I use? The answer is you start with your basic ones and learn others as requirements arise.

Again, a consultant to help guide your team is effective.

(3) A competing language issue. As long as our shop can find an alternative language that lets us continue coding in a structured manner and does a "good enough" job providing solutions, we will probably adopt the alternative language. PHP on the iSeries is very likely to become an argument for not using Java in the near future.

I see a lot of non OO PHP scripts that make me kringe. Code and UI together make a bad combination. It creates the same issues that many RPG shops have with embedded display files in their RPG instead of a layered approach.

In my opinion, you have to make the change to OO design (even if it takes a while) to achieve flexible and productive programming environments.

HTH, Paul Holm

I'm open to listening to anyone's suggestions about ways to overcome these obstacles.

Kelly