RE: Java App. Development - Is it Worth ?

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]

Larry,

Some thoughts:

1.  The problem seems to be a lack of Object-oriented design professionals.
Also, I see a hint that the people involved may not understand how to
design graphical user interfaces.  A great green screen designer is not
necessarily good at designing graphical applications.  But graphical design
is easier to learn than object-orientation.


problem i guess was not related to the design. it was the inability of the
developers to convert the design into programs in java that was the problem.
Our design strategy was the following -

 1. Design templates for frames, comboboxes, tables and other objects. The
templates were to be inherited by the calling programs. All general bits of
code was encapsulated in the templates.  Abstract methods for painting the
screen, filling the database,validations etc.. were defined. Developers are
given these templates with documentation before they start coding. Our
problem starts from there. Work not getting completed and programmers going
into endless loops of error detection and correction starts. I have to
mention here that we had an all freshers team.

2.  This appears to be a mis-match between the tools the company's
developers know and the tools in Java.  What is desired here?  What is the
required output format?  If it is only good old fashioned paper, then you
might consider invoking RPG from Java.  IBM offers PCML and you can also
use sockets or data queues.

Invoking RPG would have been a good solution if the application was to be
used on the AS400 only.


3.  The unique ID problem can be made minor.  Somewhere on the network, how
to make OS/400 data base deliver an ascending number is documented.  But,
even if you go with the Data Queue approach, you can use Object Oriented
methods to hide the OS/400 specific data queue mechanism.  If there is a
compromise to platform independence, it is a minor one and well isolated
from the other code.  Also, you can replace data queues with sockets and be
totally platform independent.


I agree. We followed the same approach. Data Queue mechanism is isolated and
a separate template is holds this function.

The question about Java versus other languages is one of requirements.

A.  If you wish platform independence and if your major market is OS/400
and iSeries, Java is required in practical terms.  C and C++ are possible,
but more difficult for most.  With C++, you still have to learn object
orientation and it is no easier in C++ (I think it is harder).  If you are
willing to stay dependent on OS/400 interfaces, RPG is fine.

i agree with u.

B.  If you are sending output to the web, or to "pdf" files, or XML, or
other nontraditional outputs, then Java is the right choice.  If you are
just accessing data base and putting out reports, RPG remains a better
choice.  If print is one of your lesser requirements, sending data to RPG
via a socket or data queue is a nice compromise, especially if your Java
skills are new.


C.  If you require a graphical user interface, Java is very likely the
correct choice.

D.  If you are doing client - server computing, I would pick Java over any
other language.  C and C++ have to deal with added problems such as byte
order and ASCII/EBCDIC.  So does C on the PC and RPG on the OS/400 side.

None of this, in my view, have anything to do with whether there is a
recession or not.  Perhaps there is a less obvious connection that is
unique to your business.  If a recession changes your requirements, then
maybe they were not requirements or not requirements this year.

Yes, there is a learning curve with Java.  Object-oriented programming
takes effort, but it is not something reserved for a favored few.  Any good
programmer can learn it.  It does take time to learn.  Graphical User
Interfaces also take some learning, but one can go a long way just by
studying similar programs that you like.  Beginners may get carried away
and have too many "controls" but this changes with experience and a little
more thought.

I can tell you this -- once you learn object-oriented programming, you will
vastly prefer it to procedural code.  Almost everyone I know who prefers
procedural to object-oriented never mastered object-oriented.  Those that
master object-oriented do not look back.  Neither do their businesses.


I agree with these set of points.





Larry W. Loen  -   Senior Linux, Java, and iSeries Performance Analyst
                          Dept HP4, Rochester MN

.. . .speaking on his own, not for IBM


Thank You

Vijosh





_______________________________________________
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l
or email: JAVA400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.


--