[configuration2]: AbstractConfiguration::getArray

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[configuration2]: AbstractConfiguration::getArray

Rainer Hirschmiller
Hi.

I wonder why AbstractConfiguration::getArray(cls, key) returns a single
object, not an array of objects? Can somebody explain why the caller
have to make an explicit cast?

e.g.
AbstractConfiguration &configuration = ....;

Object obj = configuration.getArray(String.class, "key);
// expected Object[] obj = configuration.getArray(String.class, "key);


Regards
Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Oliver Heger-3
Hi Rainer,

Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:

> Hi.
>
> I wonder why AbstractConfiguration::getArray(cls, key) returns a single
> object, not an array of objects? Can somebody explain why the caller
> have to make an explicit cast?
>
> e.g.
> AbstractConfiguration &configuration = ....;
>
> Object obj = configuration.getArray(String.class, "key);
> // expected Object[] obj = configuration.getArray(String.class, "key);
>

the explanation can be found in the Javadocs of the ConversionHandler
interface which is used behind the scenes. Citing from the docs of the
toArray() method:

"Note that the result type of this method is Object; because this method
can also produce arrays of a primitive type the return type Object[]
cannot be used."

Oliver

>
> Regards
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Jörg Schaible-5
Hi Oliver,

Oliver Heger wrote:

> Hi Rainer,
>
> Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:
>> Hi.
>>
>> I wonder why AbstractConfiguration::getArray(cls, key) returns a single
>> object, not an array of objects? Can somebody explain why the caller
>> have to make an explicit cast?
>>
>> e.g.
>> AbstractConfiguration &configuration = ....;
>>
>> Object obj = configuration.getArray(String.class, "key);
>> // expected Object[] obj = configuration.getArray(String.class, "key);
>>
>
> the explanation can be found in the Javadocs of the ConversionHandler
> interface which is used behind the scenes. Citing from the docs of the
> toArray() method:
>
> "Note that the result type of this method is Object; because this method
> can also produce arrays of a primitive type the return type Object[]
> cannot be used."

That does not explain, why the method is not declared using generics:

  public <T> T[] toArray(Class<T> cls, String key);

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Charles Honton
Try casting Object[] to long[]. The compiler and the runtime will complain.

> On Apr 27, 2016, at 11:59 PM, Jörg Schaible <[hidden email]> wrote:
>
> Hi Oliver,
>
> Oliver Heger wrote:
>
>> Hi Rainer,
>>
>>> Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:
>>> Hi.
>>>
>>> I wonder why AbstractConfiguration::getArray(cls, key) returns a single
>>> object, not an array of objects? Can somebody explain why the caller
>>> have to make an explicit cast?
>>>
>>> e.g.
>>> AbstractConfiguration &configuration = ....;
>>>
>>> Object obj = configuration.getArray(String.class, "key);
>>> // expected Object[] obj = configuration.getArray(String.class, "key);
>>
>> the explanation can be found in the Javadocs of the ConversionHandler
>> interface which is used behind the scenes. Citing from the docs of the
>> toArray() method:
>>
>> "Note that the result type of this method is Object; because this method
>> can also produce arrays of a primitive type the return type Object[]
>> cannot be used."
>
> That does not explain, why the method is not declared using generics:
>
>  public <T> T[] toArray(Class<T> cls, String key);
>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Jörg Schaible-5
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.

>
>> On Apr 27, 2016, at 11:59 PM, Jörg Schaible
>> <[hidden email]> wrote:
>>
>> Hi Oliver,
>>
>> Oliver Heger wrote:
>>
>>> Hi Rainer,
>>>
>>>> Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:
>>>> Hi.
>>>>
>>>> I wonder why AbstractConfiguration::getArray(cls, key) returns a single
>>>> object, not an array of objects? Can somebody explain why the caller
>>>> have to make an explicit cast?
>>>>
>>>> e.g.
>>>> AbstractConfiguration &configuration = ....;
>>>>
>>>> Object obj = configuration.getArray(String.class, "key);
>>>> // expected Object[] obj = configuration.getArray(String.class, "key);
>>>
>>> the explanation can be found in the Javadocs of the ConversionHandler
>>> interface which is used behind the scenes. Citing from the docs of the
>>> toArray() method:
>>>
>>> "Note that the result type of this method is Object; because this method
>>> can also produce arrays of a primitive type the return type Object[]
>>> cannot be used."
>>
>> That does not explain, why the method is not declared using generics:
>>
>>  public <T> T[] toArray(Class<T> cls, String key);
>>
>> Cheers,
>> Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Oliver Heger-3
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[].

Oliver

>
>>
>>> On Apr 27, 2016, at 11:59 PM, Jörg Schaible
>>> <[hidden email]> wrote:
>>>
>>> Hi Oliver,
>>>
>>> Oliver Heger wrote:
>>>
>>>> Hi Rainer,
>>>>
>>>>> Am 27.04.2016 um 21:22 schrieb Rainer Hirschmiller:
>>>>> Hi.
>>>>>
>>>>> I wonder why AbstractConfiguration::getArray(cls, key) returns a single
>>>>> object, not an array of objects? Can somebody explain why the caller
>>>>> have to make an explicit cast?
>>>>>
>>>>> e.g.
>>>>> AbstractConfiguration &configuration = ....;
>>>>>
>>>>> Object obj = configuration.getArray(String.class, "key);
>>>>> // expected Object[] obj = configuration.getArray(String.class, "key);
>>>>
>>>> the explanation can be found in the Javadocs of the ConversionHandler
>>>> interface which is used behind the scenes. Citing from the docs of the
>>>> toArray() method:
>>>>
>>>> "Note that the result type of this method is Object; because this method
>>>> can also produce arrays of a primitive type the return type Object[]
>>>> cannot be used."
>>>
>>> That does not explain, why the method is not declared using generics:
>>>
>>>  public <T> T[] toArray(Class<T> cls, String key);
>>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Jörg Schaible-5
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Charles Honton
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> T[] newEmptyArray(Class<T> cls) {
         return (T[]) Array.newInstance(cls, 0);
     }

     /**
      * Can't overload method because type erasure is same
      */
     public int[] newEmptyIntArray(Class<int[]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Jörg Schaible
[hidden email] 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> T get(Class<T> cls, String key);

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

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Oliver Heger-3


Am 29.04.2016 um 20:36 schrieb Jörg Schaible:

> [hidden email] 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> T get(Class<T> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [configuration2]: AbstractConfiguration::getArray

Jörg Schaible
Oliver Heger wrote:

>
>
>
> Am 29.04.2016 um 20:36 schrieb Jörg Schaible:
>> [hidden email] 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> T get(Class<T> 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?

Done: CONFIGURATION-626

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]