i write a class which uses the import de.xyz.abc and put 2 different classes with this name and package on the class path (in 2 seperate jars) which one does he use? Or does the JVM prevent this somehow?
No, the JVM does not prevent this, and it can lead to problems, especially if -for example- the classpath contains different versions of some library.
The first thing to understand is the classloader hierarchy. Classes that are part of the Java class libraries are loaded by a higher-level classloader than classes loaded through the application classloader - which means that those classes in xml-apis.jar will never be used on a JRE that has them built in. "Higher level" means: that's where the JVM looks for classes first.
This can actually be a problem if you want to use a newer version of a library that ships with the JRE (like JAX-WS, JAXB and JAXP); there's an official workaround called
endorsed directory, though.
In an app server -or
servlet container- the hierarchy gets more complicated. There's the JRE's class loader, underneath that is the server's classloader, and then there are separate classloaders for each web app on an even lower level. This ensures that each web app can have its own version of everything, and not get in the way of any other application.
Now, you're asking about jar files that are on the same level in the classloader hierarchy - that can, and will, cause problems. Avoid it at all costs. Which of identically-named classes will be loaded may depend on the name of the jar file, and it may depend on other opaque factors. Generally it can cause rather cryptic error messages when it fails, about wrong method signatures, missing methods, abstract classes etc.
The high-end solution to dealing with library version conflicts is to use something like OSGi, which can handle different versions of the same library, and can control very precisely which code gets to see which versions. I can't tell from your description if that wouldn't be overkill, though.