Am 17.02.2011 08:34, schrieb Jörg Schaible:
Hi,
Oliver Heger wrote:
Am 17.02.2011 02:10, schrieb Ralph Goers:
Thanks. But I have a larger issue.
We have been doing performance testing and the synchronization in
AbstractFileConfiguration, DynamicCombinedConfiguration, and
MultiFileHierarchicalConfiguration are showing up as predominant hot
spots. These would be easy to fix if I could use java.util.concurrent
but, of course, that would require an upgrade to Java 5. The experimental
branch has a minimum version of Java 5 but it is nowhere near ready for a
release. I'm wondering when the right time to upgrade would be? 1.8?
Ralph
This is really a good question. AFAIK other Commons components switched
to Java 1.5 only in a major release, but given the current situation
with end of support for older JDKs, it may be worth starting a new
discussion.
OTOH I would not have a major problem with switching to Java 1.5, doing
some slight API improvements by introducing generics etc., and calling
this version 2.0. (Maybe we have then again a discussion whether package
names must be changed.)
as long as we manage to stay binary compatible to current 1.6, it does
IMHO not matter if we define now Java 5 to be minimum for 1.7. Even if we
introduce generics in some places.
However, when we start to create incompatible changes and a real
refactoring/cleanup I am all for 2.0 with a renamed package ;-)
+1
I am not very happy with the experimental branch, too. If time permits,
I would like to start something new in the sandbox from scratch to
overcome some of the problems in our current design (e.g. the tight
coupling of the reloading mechanism which causes these synchronization
problems).
We actually stayed with the non-hierarchical configurations in our codebase,
since we detected at some point a significant loss of memory (sorry, it's
been too long now (~3 years) to give details).
Hm, not sure whether this is correct. In the current version of the
experimental branch most concrete Configuration implementations are
hierarchical, including typical "flat" ones like
PropertiesConfiguration, INIConfiguration, or DatabaseConfiguration.
This is probably less efficient than holding the data in a plain map,
but I cannot remember that we had a discussion about increased memory
consumption or that there were some benchmarks.
Oliver
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
