Cost of class downcasting.

Question

Hello:
I've lots of methods which return arrays of values resulting from queries to a DB. They're returned as arrays of Objects. Since these values are limited to be of one of several well known types, I get their classes using getClass () and use equals () to compare them against the classes which they may be instances of (String, BigDecimal, Date, Integer, Short and a few more). Then I downcast the values to their original types to process them as necessary (i.e. for localization tasks). Since I can elude the use of the "instanceof" operator (because I know the specific classes) and the equals () method of Class internally just does a simple comparison with the "==" operator, I have always considered it a good way of doing this task.
Well, months ago I read a very old article from JavaWorld (dated on 1999) which recommended to avoid downcasting as much as possible because of cost reasons. Although the JVMs have improved a lot since then, because these methods which I'm talking about are performed very often, Do you think that I should look for another way?
By the way, I use arrays of Objects instead of specific beans because I already use entity beans internally and these results don't correspond to concrete concepts of anything. Basically they're a bunch of mixed values from complex queries.
To avoid so much downcasting I had thought about making a common class which worked as a generic container and used 5 or 6 methods to return values of specific types. For example I'd call getDates () to get only Dates (if any), and so on.
What's your opinion? Thanks in advance.

Answer 1

gnat: Very interesting article. He describes my case very well. I tend to carry my ideas from other languages to Java, and that's a problem. I've to try hard to model my mind in a different manner.
njb7ty: Oh, yes, I'm going to try to explain it at the best way that I'm able. I've an enterprise application (.ear) running into a JBoss server. It contains one EJB application (.jar) and, on the other hand, a Web application (.war). I've designed my project that way to isolate all the work with the DB in several EJBs which provide services or tasks to the Web application, which knows nothing about the logic behind. So, in other words, the Web application demands for a limited set of operations to the EJBs, without the need of knowing anything about the table names, real field names, etc. Useful to share work among teams or even companies without risk.
For example, let's suppose that I want to list information about students and their corresponding parents. I just would retrieve the EJB dedicated to handle anything related to students and use a function called listStudentsWithParents () . This would return a list or an iterator which contains arrays of Objects (Strings for names and surnames, Dates for birhtdays, etc.) One array per "row".
Into the EJB side I'm in fact already using classes which represent entities. They're beans: they have their attributes, their corresponding getter and setter methods, etc. One entity per table. However, in the Web side it has no sense to receive (nor its convenient in my opinion) objects which represent such entities, as the needed information is just a "bunch" of mixed data from different entities which has no autonomy or meaning as a whole.
That's why I was thinking about a re-usable and generic container which replaced the array of objects and allowed me to store up to 6 or 7 kinds of types without the need of casting. Internally it'd contain 6 or 7 arrays, each one with its corresponding type. This would work for every method which needed it.