I'm also in favour of that idea. Jarcec
On Tue, Aug 14, 2012 at 11:40:17AM +0100, Brock Noland wrote: > Hi, > > I think this makes sense. Can we clearly state and define a contract for > Public and Internal? > > Brock > > On Tue, Aug 14, 2012 at 10:38 AM, Mike Percy <[email protected]> wrote: > > > It seems we have reached a point in some of the Flume components where we > > want to add features but that means adding new interfaces to maintain > > backwards compatibility. While this is natural, the more we do it, and the > > more we cast from interface to interface, the less readable and consistent > > the codebase becomes. Also, we have exposed much of our code as public > > class + public method, even when APIs may not be intended as stable > > extension points, for testing or other reasons. A few years ago, Hadoop > > faced this problem and ended up implementing annotations to document APIs > > as @Stable/@Evolving, @Public/@Limited/@Private. See < > > https://issues.apache.org/jira/browse/HADOOP-5073> for the history on > > that. > > > > I would like to propose the adoption of a similar mechanism in Flume, in > > order to give us more wiggle room in the future for evolutionary > > development. Thoughts? > > > > Right now, I feel we would get most of the bang for the buck simply by > > adding two annotations: @Public and @Internal, which to me means "you can > > subclass or instantiate this directly", or "you can't directly use this if > > you expect future compatibility". > > > > Regards, > > Mike > > > > > > -- > Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
signature.asc
Description: Digital signature
