Thanks David!

To be clear: If I am skeptical about some of these legacy performance improvements, it is precisely for the reason you stated - the JVM was much slower back when some of them were created, and there is a chance we don't need them any more.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 9/17/2014 6:42 AM, David E. Jones wrote:

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 <[email protected]> 
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


Reply via email to