commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [POOL] changes for 2.0 - how much needs to be deprecated now?
Date Fri, 23 Apr 2010 22:58:21 GMT
We could have stages:
- Now: Mark all methods we want as deprecated, which gives us a record of intention at least.
- 2.0: Drop private and package private deprecated methods
- 2.1: Drop protected and public deprecated methods

Gary Gregory
Senior Software Engineer
Seagull Software
email: ggregory@seagullsoftware.com
email: ggregory@apache.org
www.seagullsoftware.com 


> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Friday, April 23, 2010 12:42
> To: Commons Developers List
> Subject: [POOL] changes for 2.0 - how much needs to be deprecated now?
> 
> There are a lot of classes which have setters for private fields that
> are also set by the constructors.
> 
> In most cases there is no need to change the values of the fields
> after construction, so the setters could be dropped and the fields
> made final thus improving thread-safety.
> Final fields also make testing easier - fewer states to check.
> 
> (In some cases using the setter after the class has been in use for a
> while might well cause problems even if all access is thread-safe -
> e.g. changing LIFO behaviour midstream would not make sense.)
> 
> Dropping the setter methods is an API change, so my question is:
> Do all such changes have to be flagged up by deprecating the setters
> in a previous release?
> Or can a major release just drop the methods?
> 
> If deprecation is required, then we should probably start adding
> deprecated annotations now.
> I suspect there will be quite a lot.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message