commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Exception handling - was Automatic reloading
Date Mon, 22 Dec 2003 11:04:07 GMT
I don't know the preferred policy for API changes. From monitoring this 
list I got the impression that this can be complicated: old methods 
first have to be deprecated before they can be removed/replaced in a 
later release.

I am not sure if deprecation helps in all cases, e.g. if a method's 
return value is to be changed or its throws clause.

If you think that API changes are no problem after a first release, then 
I am fully happy with it. Otherwise I would suggest doing this clean up 


Emmanuel Bourg schrieb:

> Eric Pugh wrote:
>> Re: [configuration] Exception handling - was Automatic reloadingI 
>> would like
>> to move on a 1.0 very aggressively now that the vote has passed.  Part 
>> of me
>> feels that we should basically take the code as is and make that be 
>> 1.0.  It
>> is very well tested, stable, and in use in some projects.  By cutting 
>> a 1.0,
>> then we can take our time thinking about the best way to extend
>> configuration.  Right now there seem to be a couple ideas floating about:
>> 1) Reloadable Configurations.  Change a configuration from a static to a
>> dynamic set of data.  This may drag along ideas like a reloading strategy
>> etc..
> I think this feature can wait the 1.1 release. This will let some time 
> to test and refine the code.
>> 2) Extend getters..   Add more different types of gets..
> This could be included in the 1.0 release, the implementation is quite 
> straightforward. I think the basic types found in java.util (Date, 
> Calendar, TimeZone, Locale, Currency), (URI, URL), java.text 
> (DateFormat, NumberFormat, MessageFormat) are good candidates for the 
> new getters.
> Regarding getters I would also consider changing the getVector() methods 
> into getList() before 1.0.
>> 3) Better Exception handling.  The more sophisticated Configuration gets,
>> the more types of exceptions we need to deal with.
> We should at least include a basic ConfigurationException in the 1.0 
> release, the hierarchy could be built later if needed.
>> By having a 1.0 out of the way, we can start on 1.1 which might 
>> include work
>> in these three areas without feeling pressure to jam something out quick
>> just to get it in pre 1.0.   I would rather release often and have the 
>> API
>> change then stall until we are happy with everything in the API!
>> Comments?
>> Eric
> We will be reluctant to make changes breaking the compatibility after 
> the 1.0 release. That's why I think we should clean the API before the 
> first official release.
> Emmanuel Bourg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message