Strategic Java Usage/Productivity

Nathan/All

Thanks for the clarification of your points.

 The point I was trying to make is that Java and its OO capability can lead
to
much much higher levels of productivity than procedural and RPG languages in
both utilities and application
development projects.  I am not an RPG expert so I might be missing
something(s), please excuse/correct me if I'm off.  The flexibility and
productivity possible via inheritance, polymorphism, frameworks, and
interfaces would be very difficult or impossible to match with procedural
languages.

I agree that performance can be an issue with complex objects but that all
depends on the object/framework design in my experience.  Frameworks and
components; that's where I enjoy spending most of my time, especially since
I can't afford to golf daily which is my other passion</sigh>.  Inquiry
objects with inherited "maintenance" method for insert, update, delete, copy
can carry minimal overhead and the payback is huge in terms of programmer
productivity.

For example, I built and deployed, an additional inquiry operation which
returns a completely generic Java component with inherited but overridable
maintenance methods (insert, update, delete, copy) and it performs very
well.  This "department" inquiry was developed and deployed in 45 seconds
using  a set of Java components.  That's where I think AS400 shops and
others can benefit from OO and Java technology.

http://www.planetjavainc.com/wow60/runApp?id=298

Java methods are attached to the class so even multiple instances of the
components have much less overhead than people suspect.  For example, in
addition to the inherited maintenance methods, the framework/component also
inherits:  MS EXCEL, XML, web services, dynamic field level security and
validation, dynamic associations for linking files to other files, column
level sorting (black triangles), dynamic column headers, and several other
features.  All features inherited, customizable, to any database, on any
platform with zero programming effort needed; all in 45 seconds.

That's what Java and OO/frameworks can provide.

As far as the XML to HTML performance,  I haven't worked with it too much
but I imagine having to parse and regenerate the UI on the fly could be
expensive;  I don't know enough about that to comment.  Have a good
ne.  -Paul Holm



Paul,

I agree there's a place for utilities.  BTW, the HTML interface you
referenced in your 1st post was quite appealing.  Some people may not
realize that procedural languages work well for writing utilities.  Without
over-extending, a tool like WRKDBF might even be modified to deploy an HTML
interface.

My concern about performance was relative to writing extensions or wrappers
around generic utilities.  If an application requirement is for inquiry, but
the application extends a component that supports maintenance as well as
inquiry, it could lead to running a lot of oversized components.

For example, say a Servlet instantiates an object that's capable of
transforming XML into HTML using XSL.  XML Style Sheets (XSL) are
essentially programs, and running them requires a fairly complex,
interpretive runtime environment.  Instantiating a robust, interpretive,
runtime environment from within every Servlet could lead to performance
problems.

We sometimes dwell on the power of complex objects without considering that
they're eventually transformed into a boatload of machine instructions, and
allocate large blocks of memory, that must be piped through a CPU.

One key to performance may be implementing interfaces and instructions that
do no more and no less than what's required.

Nathan.