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