[
https://issues.apache.org/jira/browse/HADOOP-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618284#action_12618284
]
Tom White commented on HADOOP-3822:
-----------------------------------
bq. Can you summarize?
According to Joshua Bloch, the virtues are all to do with the fact that
interfaces don't enforce a hierarchy on your design in the way that abstract
classes do. This chimes with another principle in the book: "Favor composition
over inheritance". So for example, you can retrofit existing classes to
implement interfaces (you often can't do this with abstract classes - it
"causes great collateral damage to the type hierarchy"); also you can define
mixins and non-hierarchical type frameworks with interfaces. However, he does
say that "It is far easier to evolve an abstract class than an interface"
(which is where this whole discussion started).
{quote}
Perhaps we should document these (and more) in the wiki or someplace, and try
to validate our abstract APIs against them. There are added potential pitfalls
when using abstract classes instead of interfaces, and we should work hard to
avoid them.
{quote}
+1
bq. So do we intend to permit implementations of the scheduler that are not in
Hadoop's source tree?
I think it is OK to say that we should only support those in the tree for the
time being. (That doesn't stop folks implementing their own schedulers of
course, it just means they may have have to change them from release to release
if the interfaces change.) However, I do think we should make it possible for
scheduler implementations to live in their own packages. (E.g. I think we
should do this before committing HADOOP-3746.) To do that, I suggest we do the
following:
* Repackage the current patch so the scheduler code goes in
org.apache.hadoop.mapreduce.server.scheduler (with abstract classes changed to
interfaces, as appropriate)
* Remove javadoc for the server packages (or generate it separately, labelled
as developer javadoc - see HADOOP-3742)
* Restructure the MapReduce code into org.apache.hadoop.mapreduce for the user
API (HADOOP-1230), and the server API (HADOOP-2884 - is anyone working on this
for reorganising MapReduce?)
> 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.
