[
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.
