Re: HSSF POI performance improvement with Java helper routine bugged

I appreciate the response. Our "production" environment is pure JNI from
RPG to Java, and this project's goal is to move as much of those
transactions into pure Java. This is still in a testing phase, so I
haven't put it into production without "doing more research." I've become
familiar with what static and instance variables and methods mean in a pure
Java environment, but I think I'm having problems converting these concepts
to a RPG JNI environment, and at this point coding in pure Java is not
going to be a good fit for this application or our organization.





Joe wrote:

Hi Darren,

Just a couple of quick points, please understand that I'm busy and
haven't really analyzed your efforts. I've maintained from day one that
one
is much better off avoiding calling Java from RPG . My "day one" is from
about 1997 - I'll leave it up to you to decide whether I now have 13 years
of Java experience or one year 13 times. You can check this list for
reasons to avoid JNI. I've never had a situation where it was required.
One benefit, as you've noticed, is large performance gains.

Second, using things when "I'm not really clear on what that means" is
not a good idea. Static means a class variable; i.e. there is only one for
all instances of the class. You don't even need to construct an instance
to
use it. Sounds cool, but you've just thrown away any chance of
multi-threading using that variable. If it's a constant, great (probably,)
but if it's really a variable for an instance, or intended to work as a
local variable, you can run across a class of bugs that is very difficult
to
resolve.

I'm sure you're having a great learning experience, which is worthwhile
in itself, but you may want to do more research before putting it into
production.