hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Douglas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-3048) Stringifier
Date Thu, 03 Apr 2008 18:38:24 GMT

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

Chris Douglas commented on HADOOP-3048:

bq. There is NO difference between X and Y except that the former is encapsulated in a reusable,
well documented utility function, that others can freely use...

That said functionality is encapsulated in a reusable, well documented utility function that
others can freely use is the substance of my objection. I don't think it's necessary and while
the compiler (and Hudson) can flag an unchecked cast and committers can spot-check for wanton
(and uncommented) SuppressWarnings annotations, less fastidious uses of GenericUtils functions
can slip in unnoted, unscrutinized, and unjustified. I fully agree with your reasoning, but
come to the opposite conclusion: that there is no difference between the one line of code
(that generates a warning that must be justified) and a utility function in a new class recommends
against the latter approach.

All that said, I can live with GenericsUtil if you remain convinced that it has a role. Arguing
against my self of three lines ago, most of its functionality could also fit in ReflectionUtils,
but the distinction couldn't matter less.

bq. On the issue about load/store methods being static or not, I can say that having one or
two-liner non-static functions will not hurt, but the static versions are "convenience" methods
(as stated before, their main usage will be to store/load objects to/from the configuration,
and there is no need to keep a DefaultStringifier reference for a one-time operation.), thus
I propose we introduce both static and non-static versions.

OK. If you're going to leave the statics in, then you might as well drop the instance methods
(v6 instead of v7). If someone creates an instance and keeps it around, you're right, they're
probably dealing with volumes of data that won't go into the configuration (we hope).

+1 for v6. Thanks for all your work- and rework- on this.

> Stringifier
> -----------
>                 Key: HADOOP-3048
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3048
>             Project: Hadoop Core
>          Issue Type: New Feature
>    Affects Versions: 0.17.0
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>            Priority: Blocker
>             Fix For: 0.17.0
>         Attachments: 3048-alt.patch, stringifier_v1.patch, stringifier_v2.patch, stringifier_v3.patch,
stringifier_v4.patch, stringifier_v5.patch, stringifier_v6.patch, stringifier_v7.patch
> Storing arbitrary objects in the configuration has been discussed before in HADOOP-449
and HADOOP-1873. Although enabling such functionality has the risk of encouraging people to
put big binary objects in the configuration, for some use cases passing objects to tasks is
absolutely necessary. 
> This issue will track the implementation of a Stringifier interface which stringifies
and destringifies objects. Using this implementation, developers can store objects in the
configuration and restore them later. 
> Any thoughts ?

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

View raw message