Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume >> mail # dev >> [DISCUSS] Annotating interface scope/stability in Flume

Copy link to this message
[DISCUSS] Annotating interface scope/stability in Flume
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".