Worrying about performance issues before you've documented you HAVE performance issues is the wrong approach. There are tons of articles on this topic, both here and on the web in general. Search for "premature optimization" and you'll find plenty of reading material that boils down to this:
Don't try an optimize first - write code that is easy to maintain. Have documented, specific requirements on what the performance should be, and only if you don't meet them should you look at optimizing. Even then, you should go through a formal process of determining WHERE you are having slowdowns.
By "specific requirements" i don't mean "as fast as possible". I mean "results should be returned in 3 seconds".
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Stevenson Anderson wrote: we are trying to develop a reporting tool.
 What kind of performance issues we may get..???
 How to resolve those?
Let's forget Java just for the moment. Have a look at those three statements (I've numbered them).
1. "a reporting tool" covers a pretty wide swathe of ground - about the size of Texas, actually.
2. What kind of performance issues do you think you might run into in Texas?
3. Even assuming  was remotely predictable, or conformed to any kind of pattern - there are some, as it turns out - why would you be looking for resolutions before the problem has occurred?
It sounds like you're expecting to get it wrong and, counter-intuitive as it may sound, you're more likely to get it wrong if you focus on a single issue (performance) now.
Design your reporting system the way it should be (loosely coupled, flexible, easily updated, well modeled, Object-oriented, etc, etc) and don't even think about  until you actually have a problem. Chances are that if you did your design right, you'll then be able to change the piece (or pieces) of code that are causing you problems for some "cleverer" stuff with the minimum of ripple-effect.
Another thing that's probably worth mentioning:
Very often the simplest and most cost-effective solution to your question #3: Throws lots of hardware, memory and/or network bandwidth at it.
Isn't it funny how there's always time and money enough to do it WRONG?