Hello I have a short question.
Is it possible to check if an object is an array? (in a quick way)
Like this:
Name[] names =new Name[ 2];
names[0] =new Name("john","lemon");
names[1] =new Name("piet","jan");
doSomething( names);
...
privatevoid doSomething( Object object)
{
if( object == array)
{
// do array stuff
}
else
{
// do non-array stuff
}
}
Is this possible in any way?
Thanks
private void doSomething( Object object)
{
if( object == array)
{
// do array stuff
}
else
{
// do non-array stuff
}
}
Yoinks.
I can't imagine too many scenarios where this would be a good idea.
> Like object.getClass().isArray()?
Ah stupid of me I hadn't seen that.
Thanks for your help.
>Yoinks.
>I can't imagine too many scenarios where this would be a good idea.
Im using it for a central saving to database point (with hibernate).
If it is an array, it will do a for loops of insert, otherwise a normal insert.
This way I won't have xxxxx classes full of for loops that can be minimized into the save function itself.
I don't really know about its execution speed, but can't imagine that this part of the code will be the bottleneck of your application...
I think that .getClass().isArray() can't be any faster than the instanceof-check, but I don't know if the instanceof-check is significantly faster.
> it's not a bottleneck of course, but if you might
> knew it, it wouldn't be that much to change
> all bits help I always say hehe
Best way to make your Java code performant is to write dumb, straightforward OO code, without any trickery going on. The optimizations the JVM performs are much smarter than you think they are, and since they were written by real programmers, on a time and financial budget, they concentrated on the most common programming constructs to optimize. Second-guessing where your bottlenecks might be is rarely worth the effort
> > Arrays derive from Object[], so you can use
> > > > o instanceof Object[]
> >
> > to check if o is an array.
>
> Thanks, is this in any way quicker as
> .getClass().isArray() ?
> If so I will use this
o instanceof Object[] will return false for all primitive arrays (int[], double[], etc). The .getClass().isArray() method returns true for those however.
> It's hardly anything to worry about in your case, but
> I'm pretty convinced that an array of primitives
> (int[], for example) would not be instanceof
> Object[].
You're right, it isn't. The solution above (getClass().isArray()) is fine, if this is really desirable (I'm not convinced)
> As long as you pass either an object or an array of
> objects, I suppose you should be fine with either way
> of testing.
>
> Im using it for a central saving to database point
> (with hibernate).
> If it is an array, it will do a for loops of insert,
> otherwise a normal insert.
> This way I won't have xxxxx classes full of for loops
> that can be minimized into the save function itself.
How about Iterables too.
But it would probably be better to define two methods like:
public void doSomething(Object[] array) {
... do array stuff
}
public void doSomething(Object obj) {
.. do non array stuff
}
ejp, does you varargs design accept an array argument? I'm asking out of curiosity, I haven't used varargs myself. If it does, it's really elegant. If it doesn't, I think that requiring the client to unpack the array into separate arguments is an unnecessary burden, so I would prefer Malcolms overloaded solution, it's really elegant too. Wish I had thought of either of those.
> Or one:
> [code]
> public void doSomething(Object ... objects) {
>... do all stuff stuff
> /code]
That's what im using at the moment and it works fine.
Thanks for all the other answers here.
I tried the 2 functions thing before, but it didn't work for me when I tried it, I'll try again later since all points to the function anyways it can be quickly altered.
> ejp, does you varargs design accept an array
> argument? I'm asking out of curiosity, I haven't used
> varargs myself. If it does, it's really elegant. If
> it doesn't, I think that requiring the client to
> unpack the array into separate arguments is an
> unnecessary burden, so I would prefer Malcolms
> overloaded solution, it's really elegant too. Wish I
> had thought of either of those.
Yup that works
I prefer the overloading method though, since it's cleaner.
I'll try to make that work for my code.
ok tried the overloading functions and now it works
short example code:
public void addObject( Object[] objects)
{
try
{
//init Hibernate
for( int i = 0; i < objects.length; i++)
{
session.save( objects[i]);
}
//finish hibernate
}
catch( Exception e)
{
//handle error
}
}
public void addObject( Object object)
{
try
{
//init Hibernate
this.session.save( object);
//finish hibernate
}
catch( Exception e)
{
//handle error
}
}
It works.
public void doSomething(Object... objects) {
}
We can call the above method with both an array and a single object (and with a comma separated list of objects, not shown here):
String[] anArray = { "aa", "bb" };
doSomething(anArray);
doSomething("cc");
The call giving an array gives a warning, though:
warning: non-varargs call of varargs method with inexact argument type for last parameter;
cast to java.lang.Object for a varargs call
cast to java.lang.Object[] for a non-varargs call and to suppress this warning
Probably the right solution is to declare the array element type and the varargs type the same, as in:
public void doSomething(String... objects) {
}
> Yup that works
> I prefer the overloading method though, since it's
> cleaner.
> I'll try to make that work for my code.
Cleaner? If the code is the same in both cases (as the code you posted seems to suggest), I'd say it's cleaner to write it only once. You may argue, of course, that it depends on whether you also want to have the possibility of calling doSomething(obj1, obj2). If not, it's a bit safer and cleaner to use the overloaded version and rule out the multi-arg call. And maybe the code duplication can be avoided some other way, like calling one of the overloaded methods from the other one.
> > Yup that works
> > I prefer the overloading method though, since it's
> > cleaner.
> > I'll try to make that work for my code.
>
> Cleaner? If the code is the same in both cases (as
> the code you posted seems to suggest), I'd say it's
> cleaner to write it only once. You may argue, of
> course, that it depends on whether you also want to
> have the possibility of calling doSomething(obj1,
> obj2). If not, it's a bit safer and cleaner to use
> the overloaded version and rule out the multi-arg
> call. And maybe the code duplication can be avoided
> some other way, like calling one of the overloaded
> methods from the other one.
Code working without overloading (for people who want to know):
public void addObject( Object object)
{
try
{
//init hibernate
if( object.getClass().isArray())
{
Object[] objects = (Object[]) object;
for( int i = 0; i < objects.length; i++)
{
this.session.save( objects[i]);
}
}
else
{
this.session.save( object);
}
// end hibernate
}
catch( Exception e)
{
//handle exception
}
}
