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
