Featured Article: J2EE Classloading Best Practices

Discussions

News: Featured Article: J2EE Classloading Best Practices

  1. J2EE Classloading practices are often discussed. Finding the right incantation is often a challenge, and each application server vendor seems to employ a different hierarchy. Debu Panda, of Oracle, discusses his ideas for staying out of trouble.

    Read Debu Panda in J2EE Classloading Best Practices
  2. jboss developers pay attention ;)
  3. Share libraries[ Go to top ]

    I don't quite understand how "Share libraries" becomes a best practice. Aren't J2EE applications supposed to be self-contained? From my past experience, sharing classes across applications actually makes upgrading these classes to a new version a more costly and riskier process, because you'd have to upgrade (meaning all the regression test) all the apps that use them at the same time.
  4. Share libraries[ Go to top ]

    I don't quite understand how "Share libraries" becomes a best practice. Aren't J2EE applications supposed to be self-contained?
    Sharing libraries can make a huge difference for memory usage. I am of the opinion that you should at least share all your "standard" libraries: commmon utilities like Log4J, corporate utility libraries for Security, etc.

    I admit it increases your risks for upgrades, but I think the improvement in performance pays for this.
  5. Can you elaborate? I can see saving a bit of memory because the classes are only loaded once, but that's fairly insignificant for server applications. I can also see a very slight speed saving because the JVM only has to load the libraries once, not once for each classloader repository. But where else would you gain performance? The above gains are not even close to justifying the lost portability and self-containment benefits.
  6. Can you elaborate? I can see saving a bit of memory because the classes are only loaded once, but that's fairly insignificant for server applications. I can also see a very slight speed saving because the JVM only has to load the libraries once, not once for each classloader repository. But where else would you gain performance? The above gains are not even close to justifying the lost portability and self-containment benefits.
    The above performance gains are not insignificant. Say you use Log4J, which is 640K uncompressed. Your application probably won't load all of that code into memory, so lets call it 200K. If your application server hosts ten applications, that a difference between .2 and 2M. Multiply that by a couple dozen common libraries and things start to add up.

    I will grant you one thing, though. Unshared libraries are not the biggest memory waster in J2EE apps. That would be careless use of JSP. I have seen Java appears with 1000's of JSP that brought the server to its knees in both memory use and startup time.
  7. The above performance gains are not insignificant. Say you use Log4J, which is 640K uncompressed. Your application probably won't load all of that code into memory, so lets call it 200K. If your application server hosts ten applications, that a difference between .2 and 2M. Multiply that by a couple dozen common libraries and things start to add up.
    First can we agree that it does not cause much performance impact on the CPU, because these libraries are usually loaded when the server starts, which happens in production, like, once a quarter? and then there isn't much garbage collection when it gets to classes, either.

    Now memory wise let's say they amount to 50MB in total in your scenario above. Is it a big deal for an enterprise server that usually starts with 1GB memory? Is it worth the headache and cost on the portability and upgradability? I don't think so. Take log4j as an example while we are at it, sharing the same log4j class would force all the applications to share exactly the same logging configuration. Thanks, but no thanks, I'd rather pay for that extra 1.8M. 8-)
  8. Hmm. I may need to conceed this point, or at least say that this is something on which reasonable people can disagree.
    First can we agree that it does not cause much performance impact on the CPU, because these libraries are usually loaded when the server starts, which happens in production, like, once a quarter? and then there isn't much garbage collection when it gets to classes, either.
    I can agree with that. Most companies I know end up rebooting their servers more often than that, but overall the impact of classloading is minimal, and garbage collection is a total non-issue (it should be about the same whether the classes are shared or not, the only difference would be statics).
    Now memory wise let's say they amount to 50MB in total in your scenario above. Is it a big deal for an enterprise server that usually starts with 1GB memory?
    It depends on the organization you work with. I have worked for companies whose servers had less memory than my laptop. They were constantly scraping for memory, and every trick they could use helped.

    You've got a point with the Log4J configuration, though. It is a flaw in Log4J (and Struts), IMHO. Personally I think shared libraries reduce maintenance costs, by forcing developers to work with a consistent environment across all applications, but of course, all that depends on circumstances.