[
https://issues.apache.org/jira/browse/HADOOP-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617187#action_12617187
]
Steve Loughran commented on HADOOP-3822:
----------------------------------------
with inner classes, a lot of this is moot. What is important for an abstract
class is that
* it doesn't do anything in its constructor that calls non-final methods
* it doesnt offer protected fields (better for private and protected methods)
as you can't change much from then on.
* you dont rely on package scoped fields/methods/classes
The biggest problem I have with either api choice is exception handling -you
are always stuck with whatever exceptions the api designer thought was likely.
Currently hadoop has a lot of package-private code, and that is bad because it
forces people subclassing to use that package name. This is bad for the hadoop
team, as their packages appear in the stack traces -they get to field the
support calls.
One thing we could consider is a java5 tag @Unstable or @Internal, which would
be a bit like @deprecated, and warn people that the things could change without
warning -and hence that there were no stability guarantees at all.
> 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.
