To expand a little on why it may be a SQL problem:
The number of rows returned is not as important as the amount of work done by the database to retrieve the rows.
Oracle10g PL/SQL has a built in optimisation so it will do an array fetch of 100 rows unless the developer explicitly codes their own using SELECT ... BULK COLLECT.
So given you received 25 rows in your result set, Oracle internally retrieved all of them (i.e. it havd done all the work) when you fetched the first in Java.
If one of the tables you are getting data from is large (say 1,000,000 rows) and you don't use an index to find the 25 rows of interest, then the database will have to scan the entire 1,000,000 row table to satisfy your query. Even with big iron this will take some time. I'm not even going to get into the possible inefficiencies when joining two or more tables together to get your results.
SQL_TRACE and AUTOTRACE are tools that will tell you the amount of work the database has done to retrieve your data and the access path used.
SQL Tuning is a reasonably sized study in its own right. If you are also responsible for maintaining the database code then check out:
Oracle SQL High-Performance Tuning (2nd Edition)
Guy Harrison
http://www.amazon.com/Oracle-SQL-High-Performance-Tuning-2nd/dp/0130123811/sr=8-1/qid=1163943635/ref=sr_1_1/102-5265735-4254527?ie=UTF8&s=books Or the Oracle 10g doco
Performance Tuning Guide Ch 20
on-line
http://www.oracle.com/pls/db102/to_toc?pathname=server.102%2Fb14211%2Ftoc.htm&remark=portal+%28Getting+Started%29 PDF
http://www.oracle.com/pls/db102/to_pdf?pathname=server.102%2Fb14211.pdf&remark=portal+%28Getting+Started%29 If you have a separation of resposibilties between Java Tier and Database Tier, then knowledge of SQL_TRACE/AUTOTRACE is still useful to identify where the problem lies - then if it is SQL you can let the DB Bods sort it out for you.