[
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-3048Project: 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.
