- Storing your queries separate from the reports they drive will create a mess in your database; if you are going for plain SQL queries, embed them in the report.
- Consider using SSAS (SQL Server Analysis Services), or SSRS Report Models (sometimes called a semantic model), rather than plain old SQL queries. Not always possible, but generally performs better.
- Don't put things like calculation of performance figures in procedural code like Java, or C#, it is better to make them part of a view on top of your database (such as the SSRS, or SSAS features mentioned above), they perform better, and logically sit inside your reporting stack.
The biggest disadvantage of backing your reports with stored procedures is that the report, and the query to fill it are stored separately, and whilst the report tells you what query it depends on, the stored procedures do not tell you which assets depend on them. Now, you might start off with the intention of having a strict 1-to-1 mapping of stored procedures to reports, but in my experience, somebody will try to be clever later on and layer on stored procedure on top of another, and you end up with a web of dependencies (I've spent the last 6 months on a project to slightly improve the situation at my workplace). If you maintain rigorous documentation you can deal with this, but let's face it, documentation is hard, and annoying, and almost always out of date.
A better solution to using stored procedures would be to embed the query straight in the report, this way the report and the query are coupled to each other, they reside together and you don't get other dependent assets latching on without your knowledge. I know that this flies in the face of the "conventional wisdom" about code reuse, but SQL is not code, and the dependency chains can not be determined anywhere near as easily is in compiled code.
Another disadvantage of stored procedures is that they aren't actually the best way to drive reports, especially when you are talking about calculating aggregates over a period of 25 years. SSAS (Sql Server Analysis Services) is specifically designed for this kind of querying, and it facilitates a much more user-friendly method of building queries and reports (empowering users to build reports is brilliant). Furthermore, it allows the same data to be queried through excel as pivot tables etc (which people love). Microsoft's whole direction with reporting is to move the querying out of the database, and into the SSRS/SSAS layer. You won't always be able to produce all your reports this way, and will have to fall back to a hand-written SQL query at some point, but keep it in the report.
Now, as for the question around whether the "business logic" should be in Java. If you're talking about calculations for various statisics, or KPIs, essentially static functions over the data, rather than anything that deals with user interaction, then no, you shouldn't stick those things in code. They should be a part of your reporting stack. In Microsoft-land the best place to put these is in a SSRS Model, or an Analysis Cube (in fact the 2012 products have a replacement for the cube which gives you the same concept without needing to have batch-processing step, so it works off live data).