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: ggreg...@seagullsoftware.com email: ggreg...@apache.org www.seagullsoftware.com > -----Original Message----- > From: sebb [mailto:seb...@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-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
