Use the database for what’s it good at: referential integrity checking, validation, manipulation, selection and sorting of large data sets.
Of course this depends on what you call a large dataset (relative to the amount of memory in your application servers) and how expensive it is to get the data in the first place.
Generally speaking it's much easier to add extra application servers than adding extra DB servers (this is especially true when using systems like PostgreSQL or MySQL). Therefor, many typical Java EE setups have multiple AS boxes served by one (large) central DB. In those situations I would not always blindly follow the rule of not sorting in Java.
Namely, every time I do a sort in Java on one of my application servers I'm offloading the DB. If the data is expensive to recreate (e.g. lots of aggregations over many rows) it's even faster to just do the simple sort in Java on the data that's already available on my AS. So, both total system utilization as well as performance can potentially be better. Not always, of course not, but the potential should be explored.
Don’t do this stuff in your Java code. For example, don’t write two queries and then merge the results in Java: use a join.
Even this is not always
true. In some situations you may need a resultset where the type of one of the columns is another resulset. With some DBMS specific syntax you may be able to join and aggregate values to SQL arrays, but I don't think it's easy to aggregate a group of values to a resultset. If you need this sort of thing, it's often easier to just fire off two queries, create your own resultsets for the first query and insert those in each row of the second query. (but if you know of a neat way of how to do this in standard SQL, I'm open to suggestions ;) )