[
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
