3 ms·

Given a class and its package, I know exactly how to find the original code or class file. Using the classpath, I can specify exactly the search order of class

by junon 5y ago

Given a class and its package, I know exactly how to find the original code or class file. Using the classpath, I can specify exactly the search order of classes, including overrides and whatnot, when the VM searches for them. Need to debug a Jar? Unzip it (it's just a Zip file). Jars can contain non-code resources, essentially allowing you to run an entire app using a single file, without the need to first decompress to the filesystem. Java gives you great utilities to find those resources. Classloaders can be customized and you have complete control over how the JVM sees code. It's boring, to the point, and simple to understand. I don't get how people have so many issues with them...

barbarbar 5y ago
But if it is a class that exists in multiple jars in different versions due to dependencies dependencies depend... then it is not so easy when the wrong class is loaded.
- pjmlp 5y ago
  That is why application servers use multiple classloaders isolated from each order, and in stuff like WebSphere you can even specify which overrides which.
  - barbarbar 5y ago
    I am not familiar with websphere and it is long time since I have used weblogic. Maybe it has the same feature? But it sounds like a tedious process to go through when trying to resolve such a problem. Though it also shows how serious the problem is. That the Application Server vendor builds such a feature.
    - pjmlp 5y ago
      All languages suffer from some form of "dll hell" when everyone goes through endless third party dependencies, the major difference is how those conflicts get sorted out. The solution in the Java world allows kind of shipping both conflicting libraries and still have a go at it. Other ecosystems might make you rethink the whole dependency tree instead. I guess it was similar, I never used WebLogic. https://www.ibm.com/support/pages/system/files/support/swg/swgdocs.nsf/0/85256dd00053137d8525731d007487d2/$FILE/WSTE-07-17-07-WebSphereClassLoaders.pdf https://www.ibm.com/support/pages/system/files/support/swg/s...
    - drdec 5y ago
      Classpath isolation is part of the JEE (and now Jakarta EE) specification for application servers. This guarantees that the application servers can host multiple applications without the classes in one application bring used in another. More concretely, if one application packages log4j 1.2 and another packages log4j 2, the application servers guarantees that the two log4j libraries are isolated and do not interfere with each other.
    - solarengineer 5y ago
      Tomcat provides isolation between multiple webapps on the same Tomcat instance using a classloader hierarchy [0] Barring the system classloader - where one ought not to place anything unless in dire circumstances - one gets very nice class separation. Infact, every JSP is compiled to a Java servlet and then loaded in its own classloader. To see the speed - edit a JSP page and then see how fast the change is reflected. When devs edit JSP pages and see changes, a fresh classloader picks up the new class file and the earlier classloader is discarded. Due to classloader inheritance, the new Servlet is able to access Java classes from the parent classloader (the webapp). For production deployments, and ideally for continuous integration setups where one should compile once and test and use the artifacts everywhere, one can use the pre-compilation feature [1] where the JSP pages are compiled as servlets during the compilation process itself (and not at runtime on production environments). [0] https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.... [1] https://tomcat.apache.org/tomcat-8.0-doc/jasper-howto.html#Web_Application_Compilation https://tomcat.apache.org/tomcat-8.0-doc/jasper-howto.html#W...
isbvhodnvemrwvn 5y ago
A huge disadvantage is that you can not have different versions of the same dependency used across the project - if you do it will, AT RUNTIME, fuck up your application (since Maven's dependency resolution is very primitive).
- EdwardDiego 5y ago
  But then you have the ability to exclude dependency X's dependency 1.4.0 because you're already using 1.4.8 of Y, and 99% of the time, it works. And I've had so many times when I've wished I could do this for Python dependency trees.
- junon 5y ago
  Sure you can, you just need different classloaders.
agumonkey 5y ago
I guess the span of my coding is really really small, I never really needed any of these. to me the issue is that it creates parallel graphs on top of the FS, and that people, unless spending some time reading the spec (oracle basic doc website was utterly useless for me), will have barely no visibility on. what I appreciate is that it's fully standardized in the spec, so you don't have to deal with competitive packaging systems / hygiene like in other languages.
- junon 5y ago
  > and that people, unless spending some time reading the spec (oracle basic doc website was utterly useless for me), will have barely no visibility on. It's literally modeled after PATH, which behaves exactly the same and has been used just fine for decades. I don't really see the argument here.
  - agumonkey 5y ago
    A classpath is more complex than a fs path right ? there's more nesting levels. $maven/.../foo.jar contains stuff I don't know, and the graph is also not something necessarily obvious. Or maybe I'm just too limited and confused (plausible)
    - 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

by junon 5y ago

barbarbar 5y ago

But if it is a class that exists in multiple jars in different versions due to dependencies dependencies depend... then it is not so easy when the wrong class is loaded.

pjmlp 5y ago
That is why application servers use multiple classloaders isolated from each order, and in stuff like WebSphere you can even specify which overrides which.
- barbarbar 5y ago
  I am not familiar with websphere and it is long time since I have used weblogic. Maybe it has the same feature? But it sounds like a tedious process to go through when trying to resolve such a problem. Though it also shows how serious the problem is. That the Application Server vendor builds such a feature.
  - pjmlp 5y ago
    All languages suffer from some form of "dll hell" when everyone goes through endless third party dependencies, the major difference is how those conflicts get sorted out. The solution in the Java world allows kind of shipping both conflicting libraries and still have a go at it. Other ecosystems might make you rethink the whole dependency tree instead. I guess it was similar, I never used WebLogic. https://www.ibm.com/support/pages/system/files/support/swg/swgdocs.nsf/0/85256dd00053137d8525731d007487d2/$FILE/WSTE-07-17-07-WebSphereClassLoaders.pdf https://www.ibm.com/support/pages/system/files/support/swg/s...
  - drdec 5y ago
    Classpath isolation is part of the JEE (and now Jakarta EE) specification for application servers. This guarantees that the application servers can host multiple applications without the classes in one application bring used in another. More concretely, if one application packages log4j 1.2 and another packages log4j 2, the application servers guarantees that the two log4j libraries are isolated and do not interfere with each other.
  - solarengineer 5y ago
    Tomcat provides isolation between multiple webapps on the same Tomcat instance using a classloader hierarchy [0] Barring the system classloader - where one ought not to place anything unless in dire circumstances - one gets very nice class separation. Infact, every JSP is compiled to a Java servlet and then loaded in its own classloader. To see the speed - edit a JSP page and then see how fast the change is reflected. When devs edit JSP pages and see changes, a fresh classloader picks up the new class file and the earlier classloader is discarded. Due to classloader inheritance, the new Servlet is able to access Java classes from the parent classloader (the webapp). For production deployments, and ideally for continuous integration setups where one should compile once and test and use the artifacts everywhere, one can use the pre-compilation feature [1] where the JSP pages are compiled as servlets during the compilation process itself (and not at runtime on production environments). [0] https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.... [1] https://tomcat.apache.org/tomcat-8.0-doc/jasper-howto.html#Web_Application_Compilation https://tomcat.apache.org/tomcat-8.0-doc/jasper-howto.html#W...

isbvhodnvemrwvn 5y ago

A huge disadvantage is that you can not have different versions of the same dependency used across the project - if you do it will, AT RUNTIME, fuck up your application (since Maven's dependency resolution is very primitive).

EdwardDiego 5y ago
But then you have the ability to exclude dependency X's dependency 1.4.0 because you're already using 1.4.8 of Y, and 99% of the time, it works. And I've had so many times when I've wished I could do this for Python dependency trees.
junon 5y ago
Sure you can, you just need different classloaders.

agumonkey 5y ago

I guess the span of my coding is really really small, I never really needed any of these. to me the issue is that it creates parallel graphs on top of the FS, and that people, unless spending some time reading the spec (oracle basic doc website was utterly useless for me), will have barely no visibility on. what I appreciate is that it's fully standardized in the spec, so you don't have to deal with competitive packaging systems / hygiene like in other languages.

junon 5y ago
> and that people, unless spending some time reading the spec (oracle basic doc website was utterly useless for me), will have barely no visibility on. It's literally modeled after PATH, which behaves exactly the same and has been used just fine for decades. I don't really see the argument here.
- agumonkey 5y ago
  A classpath is more complex than a fs path right ? there's more nesting levels. $maven/.../foo.jar contains stuff I don't know, and the graph is also not something necessarily obvious. Or maybe I'm just too limited and confused (plausible)
  - 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