Java Classpath Sucks

I am planning to develop this concept as I brood more over it...
Anyway here is my initial thought:

As a developer, I am interested to develop and test code.
Anything else is a pain in the neck.
I HATE configuration work. It's boring, it's non-creative, it's conceptually very low level.
YET I find myself wasting HUMONGOUS amount of time troubleshooting configuration issues, ESPECIALLY bloody CLASSPATH issues.

Classpath issues come mainly in 3 flavour:

1A) the JAR containing the class  is not available on your HD (go, download the right version, add the jar to your CLASSPATH)
or
1B) you have the JAR but it's not in your CLASSPATH (add it to the classpath)

2) you have the JAR, but it's the wrong version - you will notice usually for some unexpected exception, you will google and hopefully you will find someone saying "if you use version N of library Y then you must use version M or library X...).... download the right version, remove the previous from the CLASSPATH and add the right one

3) you have the same class in 2 different JARs, and of course the WRONG version of the class is in the JAR which appears first in the CLASSPATH.... this is a VERY nasty case, usually very hard to detect.

Now, Maven has done a good job at organizing dependencies, BUT you must use Maven, and be very organized.

So, why on earth the Java language doesn't contain some internal mechanisms to address these issues? Like, an internal Maven-like mechanisms which analyzes your code for dependencies, knows where to download the JAR and automatically does it for you and add it to your classpath?
Or, some expert system detecting the known incompatibilities and flagging them to you? Or, an automated way to detect multiple instances of the same class in the classpath?

We still have a long way to go before the Java developer job is made hassle-free.... probably by then Java will be extinct and maintained only by some nostalgic old developer.

Java founding fathers probably were aware that point 3 would be an issue, so they introduced the JAR SEALING feature.... which is basically never used by anybody and in any case addresses only some basic issues.

In Java 7 they will introduce MODULES, so a class can be accessed only by classes belonging to the same module. This adds a new  dimension to the class versioning technology. A class is no longer GLOBAL, exposed via a CLASSPATH, but only LOCAL to a MODULE.

Here http://www.slideshare.net/gal.marder/whats-expected-in-java-7-1116123 a cool presentation on what is new in Java 7.