Re: Java and OO Concepts

Joe Pluta skrev:

Money, units, etc., I use BigDecimal. For a while I used IBM's BigDecimal because it was a LOT faster, but I think recent versions of the core BigDecimal class have gotten better. Currency codes are a string.

And that's an interesting issue; I'm not big on using integers to represent strings. It's a lot easier to maintain your database when you're using real strings rather than codes. But then again, that's an RPG bias, since comparing a four character alpha field is roughly the same as comparing an integer.

So you like words (four byte values?) as they can be atomically compared instead of the more complex String comparison?

An RPG aversion against calling subroutines? *B*

Or just the subconsious doing continouos microoptimizations? That is really a mind set hard to get rid of :)

In Java, string fields add overhead and have the extra pain of not being usable in switch statements. Ugh. You're getting me to explain all the reasons I *hate* Java for business programming <grin>.

I'd like to hear them. Get it all out! Feel better!!

Depends on your needs. You can always for non-final classes make an anonymous class at assignment overriding the toString method providing better information (which is making a class for that single instance). That might be extremely helpful for post-mortem debugging with variable dumps.

I don't use dumps a lot, so I'll take your word for it. In general, though, I don't do a lot of design based on how well the class dumps

Probably not. I am just often in the situation where I need to do post-mortem debugging. You learn with time that raw object references do not help a lot...

What have you found the usual performance problems to be and how did you fix them?

The biggest problems come from people reusing code in ways it was not intended, or people modifying routines that are being reused. If you're not careful, OO can get layered dozens of layers deep and suddenly you have routines that are doing lots of gyrations when they don't need to be. There is no cure for that other than good, upfront design. And the worst case is developers use third-party routines that they don't really understand. Open source in particular can bite you in this regard, although at least with open source you can go in and find the issues, but that of course requires that you learn the intricacies of the open source code, which defeats at least part of the purpose of using third-party packages in the first place :).

So these performance problems is not per se the fault of the JVM but somebody doing stuff in the wrong place, if I understand you correctly. Probably much worse than allocating a few extra String objects :)

I agree on the varying quality of open source projects. That is where reputation comes in - I tend to expect more from a mature Jakarta project than from a stale sourceforge project with a single developer, but both may be very useful to you in the situation.