[
https://issues.apache.org/jira/browse/HADOOP-12973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15230772#comment-15230772
]
Colin Patrick McCabe edited comment on HADOOP-12973 at 4/7/16 6:27 PM:
-----------------------------------------------------------------------
Part of the reason I believe there should be a builder is because otherwise, we
have no way of adding new parameters in a backwards compatible way. For
example, if we want to add a Foobar parameter to the constructor, we can't do
that in a compatible fashion since the Factory is hard-coded to look for a
3-argument constructor with {{File, long, long}} by this code:
{code}
37 Constructor<? extends GetSpaceUsed> cons =
38 duKlass.getConstructor(File.class, long.class, long.class);
{code}
And if I accidentally implement a constructor with File, long, long that uses
those parameters for something else, weird stuff happens. For example, if I
have a constructor like this:
{{MyGetSpaceUsedSubclass(File birthdayMessage, long numberOfClowns, long
numberOfBirthdayCakes)}}, the factory will happily find it and pass it
arguments that make no sense. Or if someone not deeply familiar with the code
changes the order of the constructor parameters, we'll have things break in
weird ways. This can all be avoided by just passing the Builder object to the
constructor.
was (Author: cmccabe):
Part of the reason I believe there should be a builder is because otherwise, we
have no way of adding new parameters in a backwards compatible way. For
example, if we want to add a Foobar parameter to the constructor, we can't do
that in a compatible fashion since the Factory is hard-coded to look for a
3-argument constructor with {{File, long, long}} by this code:
{code}
37 Constructor<? extends GetSpaceUsed> cons =
38 duKlass.getConstructor(File.class, long.class, long.class);
{code}
And if I accidentally implement a constructor with File, long, long that uses
those parameters for something else, weird stuff happens. For example, if I
have a constructor like this:
{{MyGetSpaceUsedSubclass(File birthdayMessage, long numberOfClowns, long
numberOfBirthdayCakes)}}, the factory will happily find it and pass it
arguments that make no sense. This can all be avoided by just passing the
Builder object to the constructor.
> make DU pluggable
> -----------------
>
> Key: HADOOP-12973
> URL: https://issues.apache.org/jira/browse/HADOOP-12973
> Project: Hadoop Common
> Issue Type: Sub-task
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Attachments: HADOOP-12973v0.patch, HADOOP-12973v1.patch,
> HADOOP-12973v10.patch, HADOOP-12973v2.patch, HADOOP-12973v3.patch,
> HADOOP-12973v5.patch, HADOOP-12973v6.patch, HADOOP-12973v7.patch,
> HADOOP-12973v8.patch, HADOOP-12973v9.patch
>
>
> If people are concerned about replacing the call to DU. Then an easy first
> step is to make it pluggable. Then it's possible to replace it with something
> while leaving the default alone.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
