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/
