http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201006.mbox/%3c2640abb5-65b1-4cb0-b360-2a97eac2e...@me.com%3E
-Adrian
On 5/31/2012 2:08 AM, Scott Gray wrote:
Perhaps my memory is failing but haven't you raised this topic before? What
was the outcome back then?
I think if you're planning to rehash old topics then it's good to call out the previous
discussions that have been had to give a full context. While I'm not at all suggesting
you are doing this, it is entirely possible for someone with an agenda to keep raising
old topics as new ones until the desired response is received from the community, later
on when someone complains you can just say "but I discussed it first!" even if
the idea had been rejected in several previous discussions. Again, I'm not suggesting
you're doing this, just using it as an example of why it's important to disclose previous
discussions when raising them anew.
Regards
Scott
On 30/05/2012, at 11:24 PM, Adrian Crum wrote:
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