2 ms·

It's not really more complex. It's just a search path. There's no graph. It goes entry by entry, "can I load the requested class from this location? nope, okay

by junon 5y ago

It's not really more complex. It's just a search path. There's no graph. It goes entry by entry, "can I load the requested class from this location? nope, okay next." and so on, finally ending up with a ClassNotFoundException or whatever if it can't find it in any of the classpath entries. Not really any different than PATH.

agumonkey 5y ago
PATH lists folders with files (or links) it's pretty much flat classpath lists folders with jars which embeds their own subtree of classes, that's one difference in my (poor) understanding then, as far as i can recall, each class file can define package namespace so looking at the class path I have no clue what is there or what isn't so classpath errors felt more daunting to me now that the JVM does a tree search over all of this in an obvious linear manner, i can understand, but as a user i still find classpath and armies of jars very hard to map in my head (added to that the verbosity and large number of classes in many java apis) if i'm still off, then there's nothing saving me :) except maybe if you have an article about classloading and all that, that may remap my brain
- junon 5y ago
  > classpath lists folders with jars No, the classpath lists folders of classes, or actual paths to jars. Not paths to folders of jars. > then, as far as i can recall, each class file can define package namespace so looking at the class path I have no clue what is there or what isn't so classpath errors felt more daunting to me Classes are resolved from the root of the jar. Just inspect the jar to see what's in it. It's not common for third-party libraries to have conflicting package names. I don't know why you're talking about tree searches.
- stickfigure 5y ago
  The JVM doesn't look for classes in jars unless you explicitly specify the jar on the classpath. It really is just like PATH if you imagine that a jar is simply a compressed folder (which it is).

by junon 5y ago

agumonkey 5y ago

PATH lists folders with files (or links) it's pretty much flat classpath lists folders with jars which embeds their own subtree of classes, that's one difference in my (poor) understanding then, as far as i can recall, each class file can define package namespace so looking at the class path I have no clue what is there or what isn't so classpath errors felt more daunting to me now that the JVM does a tree search over all of this in an obvious linear manner, i can understand, but as a user i still find classpath and armies of jars very hard to map in my head (added to that the verbosity and large number of classes in many java apis) if i'm still off, then there's nothing saving me :) except maybe if you have an article about classloading and all that, that may remap my brain

junon 5y ago
> classpath lists folders with jars No, the classpath lists folders of classes, or actual paths to jars. Not paths to folders of jars. > then, as far as i can recall, each class file can define package namespace so looking at the class path I have no clue what is there or what isn't so classpath errors felt more daunting to me Classes are resolved from the root of the jar. Just inspect the jar to see what's in it. It's not common for third-party libraries to have conflicting package names. I don't know why you're talking about tree searches.
stickfigure 5y ago
The JVM doesn't look for classes in jars unless you explicitly specify the jar on the classpath. It really is just like PATH if you imagine that a jar is simply a compressed folder (which it is).