Daniel John Debrunner wrote:
You or I might not, but I'm assuming the worst case where the end-user has no idea about classpath, or maybe even Java. They have just installed two applications, one which uses Derby client at version X and one which uses Derby embedded at version Y.
I would hope for that kind of environment the installer for each application took care of separating the classpaths so the user was never exposed to them. After all one could be using embedded X and the other embedded Y with all sorts of unexpected consequences.
That, and nasty platform issues like the 256 char length, are why most applications have evolved away from using the environment to solutions like extension directories.
In many cases, applications /want/ to be able to load different versions concurrently, not just application servers and frameworks like Spring or OSGI but also build tools like Ant or Maven and development tools like Eclipse. None of these are able to use the traditional classpath alone.
Clarity in which jar is providing which class (once and only once) greatly simplifies things. Users can use the capabilities of the application (such as classloader hierarchies and ordering) to ensure that the correct version is used for each component without risk of cross-contamination between functions.
-- Jeremy
