I am reposting this thread with a different subject to make sure
everyone interested has a chance to comment.
To summarize (and to make sure we are all on the same page):
1. Javolution was added to the project in the JDK 1.4 days. David Jones
ran some performance tests that demonstrated a performance boost when
using Javolution Fast* classes instead of java.util.* classes.
2. Javolution acheived this performance boost by eliminating some
garbage collection. The Fast* classes use object pools - where objects
are returned to the pool when they are unused instead of being garbage
collected.
3. JDK 1.5 introduced an improved garbage collector that eliminated the
long pauses caused by previous garbage collectors. Also, it introduced
the java.util.concurrent package - which is functionally similar to
Javolution's concurrency. When OFBiz switched to the JDK 1.5
requirement, the need for Javolution was eliminated - but it was kept in
the project anyway.
4. No performance tests have been executed recently to see what kind of
impact removing Javolution will have.
5. In the attached thread I recommend removing Javolution from object
fields that are effectively static (either declared static or a field of
an object that is cached indefinitely), because the pooled object is
never returned to the pool - defeating the purpose of the library.
6. In the attached thread Adam suggests removing Javolution entirely.
-Adrian
On 5/27/2012 9:56 PM, Adrian Crum wrote:
On 5/27/2012 5:56 PM, Adam Heath wrote:
On 05/27/2012 07:09 AM, Jacques Le Roux wrote:
From: "Adrian Crum" <adrian.c...@sandglass-software.com>
FYI, in the Mini-language overhaul I interned the Element tag name
Strings.
Yes, that's really a good improvment! Things are much more clear now.
It's only in minilang though (I mean not in widgets actions yet),
right?
Another thing to discuss is the proper use of Javolution and/or
whether we still need it.
Yes, I also wondered about that last week when willing to cast to a
TreeMap.
The fact that it's a one man project and will maybe less and less
supported http://javolution.org/#HISTORY is not yet an issue but
could be
I personally see no need for javolution. It's non-standard
concurrency(java.util.concurrent). It does it's own memory
allocation, which prevents escape-analysis from working(allocating
memory on the stack instead of the heap).
In the Mini-language overhaul I removed Javolution classes from model
fields - since the models could be kept in memory (cached)
indefinitely (resulting in borrowed objects that are never returned to
the pool). I kept Javolution in the script execution path - which is
the proper use from my perspective. I know you ran into issues with
FastMap previously, but I don't remember the details.
If there are no objections, I can remove Javolution from Mini-language
entirely.
-Adrian
