[
https://issues.apache.org/jira/browse/HADOOP-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585088#action_12585088
]
enis edited comment on HADOOP-3048 at 4/3/08 8:21 AM:
---------------------------------------------------------------
There is NO difference between
{code}
public static <T> T[] toArray(Class<T> c, List<T> list)
{
@SuppressWarnings("unchecked")
T[] ta= (T[])Array.newInstance(c, list.size());
for (int i= 0; i<list.size(); i++)
ta[i]= list.get(i);
return ta;
}
{code}
and
{code}
list.toArray((T[])Array.newInstance(clazz, parts.length));
{code}
except that the former is encapsulated in a reusable, well documented utility
function, that others can freely use, so in that case I am sorry but I have to
insist on keeping GenericsUtil. Here is the Sun's implementation of
ArrayList#toArray() for reference :
{code}
public <T> T[] toArray(T[] a) {
if (a.length < size)
a = (T[])java.lang.reflect.Array.
newInstance(a.getClass().getComponentType(), size);
System.arraycopy(elementData, 0, a, 0, size);
if (a.length > size)
a[size] = null;
return a;
}
{code}
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. Static methods are not useless,
since they are already being used in the patch for HADOOP-449.
was (Author: enis):
There is NO difference between
{code}
public static <T> T[] toArray(Class<T> c, List<T> list)
{
@SuppressWarnings("unchecked")
T[] ta= (T[])Array.newInstance(c, list.size());
for (int i= 0; i<list.size(); i++)
ta[i]= list.get(i);
return ta;
}
{code}
and
{code}
list.toArray((T[])Array.newInstance(clazz, parts.length));
{code}
except that the former is encapsulated in a reusable, well documented utility
function, that others can freely use, so in that case I am sorry but I have to
insist on keeping GenericsUtil. Here is the Sun's implementation of
ArrayList#toArray() for reference :
{code}
public <T> T[] toArray(T[] a) {
if (a.length < size)
a = (T[])java.lang.reflect.Array.
newInstance(a.getClass().getComponentType(), size);
System.arraycopy(elementData, 0, a, 0, size);
if (a.length > size)
a[size] = null;
return a;
}
{code}
One 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.
> 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
>
>
> 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.
