commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Compilation under Java 1.4
Date Fri, 18 Feb 2011 20:30:46 GMT
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 ;-)


>> 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.


> - Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message