Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Mon, 17 Jun 2013 23:01:21 +0000 (UTC)
From: "Karthik Kambatla (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12652937.1371234013756.128809.1371510081609@arcas>
In-Reply-To: <JIRA.12652937.1371234013756@arcas>
References: <JIRA.12652937.1371234013756@arcas>
Subject: [jira] [Commented] (HADOOP-9646) Inconsistent exception
 specifications in FileUtils#chmod
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HADOOP-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686134#comment-13686134 ] 

Karthik Kambatla commented on HADOOP-9646:
------------------------------------------

I was referring to the compatibility between 1.x and 2.x, and our policy of deprecating the method in one major release before removing it altogether in a subsequent release.

Let us say there is a method with signature 'a', and we want to change it to 'b'. To ensure compatibility and adhere to our deprecation rules, we deprecate 'a' and add 'b', as long as the method can be overloaded with both the signatures 'a' and 'b'. This usually works fine when the signature changes are in parameters. However, when the signature changes are in adding/removing Exceptions or the return type itself, it can't be overloaded - so we can't have two versions 'a' and 'b' of the method at the same time.

branch-1 and branch-2 have the following API:
{code}  
  public static int chmod(String filename, String perm
                          ) throws IOException, InterruptedException {
    return chmod(filename, perm, false);
  }
{code}

Ideally, we would like to do the following, but can't.
{code}  
  @Deprecated
  public static int chmod(String filename, String perm
                          ) throws IOException, InterruptedException {
    return chmod(filename, perm, false);
  }

  public static int chmod(String filename, String perm
                          ) throws IOException {
    return chmod(filename, perm, false);
  }
{code}

My proposal is to allow such API source incompatible changes in a major release, without the need for deprecation. Not just for this JIRA, but any future cases along the same lines.


> Inconsistent exception specifications in FileUtils#chmod
> --------------------------------------------------------
>
>                 Key: HADOOP-9646
>                 URL: https://issues.apache.org/jira/browse/HADOOP-9646
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>            Priority: Minor
>             Fix For: 2.1.0-beta
>
>         Attachments: HADOOP-9646.001.patch, HADOOP-9646.002.patch
>
>
> There are two FileUtils#chmod methods:
> {code}
> public static int chmod(String filename, String perm
>                           ) throws IOException, InterruptedException;
> public static int chmod(String filename, String perm, boolean recursive)
>                             throws IOException;
> {code}
> The first one just calls the second one with {{recursive = false}}, but despite that it is declared as throwing {{InterruptedException}}, something the second one doesn't declare.
> The new Java7 chmod API, which we will transition to once JDK6 support is dropped, does *not* throw {{InterruptedException}}
> See [http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#setOwner(java.nio.file.Path, java.nio.file.attribute.UserPrincipal)]
> So we should make these consistent by removing the {{InterruptedException}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira