5 ms·

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 i

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...

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...