Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Message-ID: <1465368812.1253197557643.JavaMail.jira@brutus>
Date: Thu, 17 Sep 2009 07:25:57 -0700 (PDT)
From: "Tom White (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Subject: [jira] Commented: (MAPREDUCE-954) The new interface's Context
 objects should be interfaces
In-Reply-To: <181108236.1252087558290.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MAPREDUCE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756559#action_12756559 ] 

Tom White commented on MAPREDUCE-954:
-------------------------------------

I've gone back to the cases that have motivated this in order to better understand why this change is needed.

The first motivating case is MAPREDUCE-901, which needs to change the constructor to ReduceContext due to an internal type change. As noted above, user applications should never create context objects, so the constructor could be marked as Private Evolving to solve this problem, couldn't it?

The other motivating case is MAPREDUCE-372 (chain MapReduce), where various fields of the context need to be replaced with custom versions. The approach described in [this comment|https://issues.apache.org/jira/browse/MAPREDUCE-372?focusedCommentId=12752452&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12752452] which is to add a new constructor to ReduceContext (a "pseudo copy constructor"), could again be made Private Evolving to mark its scope. This approach didn't cause any information leakage as far as I can tell (the previous version had to add extra getters, which did cause leakage).

Another approach would be to create package private constructors and have a Private Evolving ContextFactory in the same package if the intent is to keep the constructors further away from user code (in IDE autocomplete, for example). The point is that I think we can avoid the problem of leakage with some changes to visibility annotations.


> The new interface's Context objects should be interfaces
> --------------------------------------------------------
>
>                 Key: MAPREDUCE-954
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-954
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: client
>            Reporter: Owen O'Malley
>            Assignee: Arun C Murthy
>             Fix For: 0.21.0
>
>         Attachments: MAPREDUCE-954.patch, MAPREDUCE-954.patch, MAPREDUCE-954.patch
>
>
> When I was doing HADOOP-1230, I was persuaded to make the Context objects as classes. I think that was a serious mistake. It caused a lot of information leakage into the public classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.