[
https://issues.apache.org/jira/browse/HADOOP-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616589#action_12616589
]
Tom White commented on HADOOP-3822:
-----------------------------------
+1 on separating developer and user APIs.
There's some discussion on this very issue in the context of
interfaces/abstract classes (yes, that again) here
http://kasparov.skife.org/blog-live/src/java/versioning-apr-almost.writeback
and here http://www.dehora.net/journal/2008/06/24/icompatible/.
Also in "Item 18: Prefer interfaces to abstract classes" of Joshua Bloch's
Effective Java (http://java.sun.com/docs/books/effective/), he extols the
virtues of interfaces over abstract classes. However, at the end he says:
{quote}
Once an interface is released and widely implemented, it is almost impossible
to change. You really must get it right the first time. If an interface
contains a minor flaw, it will irritate you and its users forever. If an
interface is severely deficient, it can doom an API. The best thing to do when
releasing a new interface is to have as many programmers as possible implement
the interface in as many ways as possible before the interface is frozen. This
will allow you to discover flaws while you can still correct them.
{quote}
So perhaps the developer API (which is "less public") is the place where it is
OK to introduce interfaces - if we feel there is a good case for them - so we
can get feedback on them by having different groups produce different
implementations before they are frozen by appearing in user javadocs.
(According to Bloch, three implementations is enough:
http://lcsd05.cs.tamu.edu/slides/keynote.pdf)
> Create a public scheduler API
> -----------------------------
>
> Key: HADOOP-3822
> URL: https://issues.apache.org/jira/browse/HADOOP-3822
> Project: Hadoop Core
> Issue Type: Improvement
> Components: mapred
> Reporter: Tom White
> Fix For: 0.19.0
>
> Attachments: hadoop-3822.patch, hadoop-3822.sh
>
>
> The work in HADOOP-3412 provided an API to support pluggable schedulers.
> However implementations have to be in the org.apache.hadoop.mapred package,
> which is undesirable. The goal of this issue is to create a public API for
> scheduler writers to code against.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
