hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-3048) Stringifier
Date Tue, 01 Apr 2008 15:00:25 GMT

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

Enis Soztutar commented on HADOOP-3048:
---------------------------------------

bq. I'm uncomfortable with GenericsUtil. It can't be denied that Java generics have some fiercely
annoying properties, but factoring this out is probably the wrong solution. 
I cannot understand why we do not want to separate the functionality to deal with generics.
The proposed functions are fairly general and can be used by others, and it seems that we
cannot get rid of them(please see below), so extracting this out is better than introducing
ad hoc solutions. 

bq. Where GenericsUtil::getClass(T) is called, Class::asSubclass(Class) should be preferred.

we cannot use Class::asSubclass(Class) get a Class<T> object where T is a generic type,
because then we would use : 
{code}
T item; 
Class<T> c = item.getClass().asSubclass(  <cannot_fill>  );
{code}
in the above code, we cannot write anything as an argument to getSubclass, since we do not
have any object of type Class<T>. (if we had then why would we bother getting an object
of the same type). GenericsUtil#getClass(T) is introduced to handle the repetitive pattern
of 
{code}
@SuppressWarnings("unchecked")
Class<T> c = (Class<T>)t.getClass(); 
{code}

bq. Similarly, GenericsUtil::toArray is called from a function that's destringifying and deserializing
objects. It's not statically-checkable code, the casts are wholly justified, and the warning
should be suppressed. Contexts where toArray might be useful should typically prefer the equally
typesafe implementation in ArrayList (this case included).

Unfortunatelly, we cannot use ArrayList#toArray(T[] a), since creating a generic array is
not allowed, similarly ArrayList#toArray() will not work either, since it returns an Object[]
and casting Object[] to T[] is not possible. Thus we needed a method to do the job of returning
a generic array from a List, that's why we have GenericsUtil::toArray(). The above cases are
clearly demonstrated in TestGenericsUtil#testWithGenericClass().

bq. Since separator is a constant, it should be in all caps
I would change that, if it matters. 

> 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: stringifier_v1.patch, stringifier_v2.patch, stringifier_v3.patch,
stringifier_v4.patch, stringifier_v5.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.


Mime
View raw message