On 3/31/2013 8:06 AM, Jacopo Cappellato wrote:
On Mar 30, 2013, at 5:46 PM, Adrian Crum <[email protected]>
wrote:
Thinking about this more, I don't think a branch will work. Javolution is
pervasive and it will take a while to remove it all. This will cause a lot of
problems keeping the branch up to date with the trunk - due to merge conflicts
(which will grow over time).
I agree that performing this task in the trunk would make our life easier; as a
side note,
I created the branch to address the concerns in the previous discussion
about the performance impact of removing Javolution. In other words, the
branch is intended to be used with profilers before the changes are
brought into the trunk. I don't think there will be any adverse effects
of removing Javolution - because I understand how it did its 'magic' in
the Java versions prior to 1.5. So, I need to find a way to convince
others before I would be willing to do the work in the trunk.
I am ready to commit some changes to disable selectively the specialpurpose components:
as we discussed we could even exclude them from the build/test process by default (the
idea is that maintaining them is "optional" i.e. it is ok to commit code to
framework/applications that breaks them but of course we are happy to accept
contributions to make specialpurpose component work)... in this way we could concentrate
on a smaller codebase (framework and applications).
Hmmm... I think I prefer removing Javolution from specialpurpose before
we remove specialpurpose.
Jacopo
I removed Javolution from Mini-language and ran the complete test suite - which
includes a lot of tests written in Mini-language. There was no difference in
execution time between the trunk version and the version that had Javolution
removed. On a side note, I already removed a lot of Javolution instances during
the Mini-language overhaul, and the overhaul improved performance by 40% - not
because I removed Javolution, but through better code quality.
I have tried to run profiling tools on OFBiz, but either the profiler crashes
or OFBiz crashes. Visual VM will make it half way through the full test suite,
then OFBiz just stops running. Looking at the performance report, it seems we
should worry more about code hot spots than a potential performance hit from
removing Javolution.
So, I don't know how to proceed. Has anyone had any success with running
profilers on OFBiz?
-Adrian
On 3/29/2013 12:42 PM, Jacopo Cappellato wrote:
Thank you Adrian
Jacopo
On Mar 29, 2013, at 12:29 PM, Adrian Crum <[email protected]>
wrote:
A discussion from about a year ago:
http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%[email protected]%3E
I can create a branch and start working on this. Does anyone want to help?
-Adrian
