hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthik Kambatla (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9646) Inconsistent exception specifications in FileUtils#chmod
Date Mon, 17 Jun 2013 23:01:21 GMT

    [ 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

Mime
View raw message