It may be fine to remove this, but I'd still recommend doing some performance tests with and without to make sure the impact isn't significant.
JVMs are much better these days about class loading, but 10 years ago that was not the case. The caching classloader alone resulted in something like a 20x performance increase for various things in OFBiz, mostly because OFBiz uses Java reflection so much to do things like run Java object methods for services and request events. In modern JVMs the performance different may be insignificant, but I'm not sure about that... some testing a couple years ago I still found a difference, though it wasn't as dramatic. -David On Sep 11, 2014, at 9:56 AM, Adrian Crum <adrian.c...@sandglass-software.com> wrote: > The CachedClassLoader was another "performance improvement" introduced by > David. I have always suspected (but never investigated thoroughly) that the > system class loader does some class caching on its own. > > I agree that class loading could be handled better - to solve jar version > conflicts for example. If I have a newer/older jar in my application, the > class loader should find it first, before looking in the OFBiz OOTB jar files. > > Anything that can be done to improve the class loader arrangement will be > wonderful. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 9/11/2014 5:46 PM, Jacopo Cappellato wrote: >> Hi all, >> >> after I spent a good amount of time studying how Java class loaders works >> and are setup in OFBiz I realized that there was room for improving some old >> code and simplify it a lot by removing the old and custom CachedClassLoader >> that is created for each of the OFBiz web applications. >> >> I am pretty confident that this change will work well and that will make the >> framework code that manages classloaders easier to read and maintain, and >> will also be a small step in the direction of making OFBiz easier to deploy >> on external application servers, with no penalties for performance. >> My preference would be to commit the code in the trunk (no API changes or >> other impact for the applications and external configuration) and then let >> you review my work. >> If, on the other hand, you prefer I submit a patch to Jira, I will be happy >> too. >> >> Please let me know. >> >> Jacopo >>
