RE: Strategic Java Usage

> I'm not sure I'm understanding all your
> points relative to utilitarian interfaces nor
> the performance impacts you mention.

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.