since the locations of libraries (specifically tools.jar) changes from system to system.
This is even less robust because you don't know if a user has the JDK.
Agreed, and that's why I had to write a launcher for the program: need to find the JDK install, its tools.jar, add it to a classpath, then launch the app. I should have clarified the context: my team (at the time) was hoping to run the application as a single executable jar. However, the tools.jar is system-dependent, so it seemed foolish to attempt to repackage our tool for every single java installation; this would lead to a maintenance nightmare, if it would even work at all. Java WebStart allows you to run an app with multiple jars instead of one executable jar; however, I don't think you can get to the user's JDK install automagically that way either. Hence, we're stuck with a custom launcher that does the work of hunting down the installation.
I didn't mean to imply that manifest classpaths are bad; just that they're not robust. They work perfectly for many applications, but they are useless for any case where you do not know the directory structure of the client ahead of time, and they break if the client makes changes to that structure.