Re: [configuration2]: AbstractConfiguration::getArray

[Oliver Heger]

Am 29.04.2016 um 20:36 schrieb Jörg Schaible:
> c...@honton.org wrote:
> 
>> Jorge,
>>
>> You could create a different named method for each primitive array
>> type.  Would be a pain to use in a generic fashion.
> 
> 
> [snip]
> 
> I agree with a method returning explicitly an array, but that has been 
> nonsense in first place.
> 
> As I already pointed out, the existing
> 
>   T get(Class cls, String key);
> 
> would have been completely enough. See my examples from the last mail.

IIRC get() currently cannot handle arrays, but this should be easy to
add. So could you please open a Jira ticket to track this?

Thanks
Oliver

> 
> Cheers,
> Jörg
> 
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [configuration2]: AbstractConfiguration::getArray

[Jörg Schaible]

c...@honton.org wrote:

> Jorge,
> 
> You could create a different named method for each primitive array
> type.  Would be a pain to use in a generic fashion.


[snip]

I agree with a method returning explicitly an array, but that has been 
nonsense in first place.

As I already pointed out, the existing

  T get(Class cls, String key);

would have been completely enough. See my examples from the last mail.

Cheers,
Jörg


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [configuration2]: AbstractConfiguration::getArray

[chas]

Jorge,

You could create a different named method for each primitive array  
type.  Would be a pain to use in a generic fashion.


Play with the following sample code to see why the return type
needs to be Object.

regards,
chas



import java.lang.reflect.Array;
import java.lang.reflect.Field;

import org.junit.Test;

public class GenericCastTest {

@SuppressWarnings("unchecked")
public  T[] newEmptyArray(Class cls) {
return (T[]) Array.newInstance(cls, 0);
}

/**
 * Can't overload method because type erasure is same
 */
public int[] newEmptyIntArray(Class cls, String key) {
return (int[]) Array.newInstance(cls, 0);
}

public static class ConfigPojo {
public int[] intParam;
}

@Test(expected=ClassCastException.class)
public void useObjectReturn() throws IllegalArgumentException,  
IllegalAccessException {

// won't compile
// int[] empty = newEmptyArray(Integer.TYPE);

ConfigPojo cp = new ConfigPojo();
fillWithEmptyArrays(cp);
}

private void fillWithEmptyArrays(Object cp) throws  
IllegalArgumentException, IllegalAccessException {

for(Field field : cp.getClass().getFields()) {
if(field.getType().isArray()) {
field.set(cp,  
newEmptyArray(field.getType().getComponentType()));

}
}
   }
}



-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [configuration2]: AbstractConfiguration::getArray

[Jörg Schaible]

Hi Oliver,

Oliver Heger wrote:

> Hi Jörg,
> 
> Am 28.04.2016 um 16:34 schrieb Jörg Schaible:
>> Chas Honton wrote:
>> 
>>> Try casting Object[] to long[]. The compiler and the runtime will
>>> complain.
>> 
>> It is not about a cast, it's about returning the proper object. And it
>> has nothing to do with primitives, because you cannot cast e.g. Object[]
>> to String[] either.
> 
> my first idea was the generic version, too. However, as Chas said, it is
> not possible to make a method with such a signature return an array of
> primitives. After type erasure, you have
> 
> public Object[] toArray(Class cls, String key)
> 
> and a primitive array is not an Object[].

The question is, why do we have getArray at all? These calls should be 
completely valid:

String[] strArray = conf.get(String[].class, "strings");
Integer[] integerArray = conf.get(Integer[].class, "integers");
int[] intArray = conf.get(int[].class, "ints");

... and I have implemented something like this in the past.

Method getArray should be deprecated immediately. Especially if it is not 
possible to use it in a type-safe way.

Cheers,
Jörg


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org