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



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.