DON'T DO IT!
You're approaching the problem of re-writing a program with a relatively small amount of information from one client solution to a new client solution (MS Access to Java) while still using the same server platform (SQL Server 2008). This is a bad idea. Even if you find one-to-one matches for every class and feature you want, you're still throwing away a known code-base for a brand-new set of bugs.
If you're pulling data down from SQL Server Reporting Services to generate an MS Access Report that you save as a PDF and email to someone, you're already using a perfect acceptable tool in exactly the domain said tool was designed for. While there are other tools that could produce the same solution, unless your problem domain is fundamentally changing you don't want to change one line of that MS Access app if you don't have to.
But it's an MS Access Application (.APP), and those aren't supported in 2013...
Yes, *.app files are gone, and if you have an application written using them, and you don't want to jump on the SharePoint bandwagon, you may very well have a bonna fide need to touch otherwise perfectly working code.
But, in that case, the solution is not to throw away the entire access code base and start again. Instead, since all of your data is already on SQL server, you can just create an MS Access Desktop database and link the tables and views you need as either "linked tables" or pass-through queries. At worst, you may need to search through your code base and change references like "dbo.stuff" to either "dbo_stuff" or "stuff", depending on your naming convention.
No, it's a company policy, as we're a Java Shop...
Then you already have program standards. Follow those, and not random strangers on the internet.
Actually, we're moving mostly to android tablets and iPads and stuff, and want to support them...
Great. Then you want to make a new web-based "client" to your SQL server, that should work alongside of your Access application instead of having to do EVERYTHING on first release.
I'm a big fan of XSLT for the sort of reports that Access produces, although they're hardly user-friendly. (XSLT is almost a programming language by itself.) I know that Java can do the kind of user-friendly drag-and-drop kind of stuff that Access can do, but that's more of a specific platform question than a general programming inquiry.
Ok, you got me. I'm really just a Java-fluent IT support in a small office who inherited this boondoggle and want to re-do it in anything but Access.
Neat. Java's not a bad choice at all to move your office's home-grown application to, especially if you're small enough that Apple or Linux is a real possibility. But, as with the stub answer above about making a web interface, don't try and replace EVERYTHING right away. Pick a solution that offers some useful benefits, and start there. If necessary, you can even call back to Access via COM or by sending windows command-line calls.
Hey, I'm not just some kid out of college! Java as %SOME_FEATURE% we want to use, and we're going to use it!
Great. Go for it. Submit more questions with the particular hangups you have in replicating a use-case from Access with your chosen Java toolkit. But "Java" is almost as broad as "programming", and doesn't really help anyone offer advice until you get a little more specific.
Was there a single answer in there somewhere?
Sure.
Don't do it if you don't have to.
Don't replicate everything your access app does if you can run them side-by-side for a short while. If all the data is on SQL server, you can connect to different client platforms at once, without having to shut down one over the other.
Figure out what your future platform needs and existing enterprise choices are, and go there. If you already have a web server, use that. If you already use some swing apps, do those instead.
