How do I find the runtime class of calling object from a static method?

[Sean Knapp]

Okay, here is the setup:

Class A has a static method foo, and a normal (non-static) method bar. foo
is called by bar. In foo, I need to find the actual class of the object that
just called me.

The tricky part is this: Class A has dozens of sub-classes, all of which use
the method bar, but never overide it.

The code looks like this:

class A {
public void bar() {
foo();
}

static public void foo() {
// Find calling class type
}
}

class B extends A {
}

class C {
public static void main(String[] args) {
new A().bar();
}
}

I know about the SecurityManager.getClassContext() trick which works great,
except for this case, since class B never shows up on the stack trace
because it's superclass method is called.

I know I could also simply pass in the class object from this.getClass() in
bar, but I have dozens of these methods and would much prefer a more elegant
solution that multiple wrapper classes.

As far as I can figure, it seems I need to somehow get the corresponding
objects to these classes found on the stack in order to use the getClass()
method, but am completely stuck as how to do this.

If anybody has any insight into this, please let me know, you'll make my
month!

Thank you in advance!
Regards,
Sean Knapp

 

[Jose Rubio]

The more elegant and pure OO way is to use polymorphism. So each class would
override foo() to determine what type it is. Having the supeclass determine
the type of subclass objects in my opinion is bad OO design.

class B extends A {
}

class C {
public static void main(String[] args) {
new A().bar();

This actually doesn't call anything in B. So I don't know what you are
trying to accomplish here.

 

[Chris Smith]

Okay, here is the setup:

Class A has a static method foo, and a normal (non-static) method bar. foo
is called by bar. In foo, I need to find the actual class of the object that
just called me.

What do you intend to do with it? I ask this because there are several
strategies for dealing with this general challenge, and some are more or
less appropriate depending on the context. If, for example, you are
trying to get logging or debugging information, then inspecting the
stack trace from a Throwable instance could be a good idea (though I'm
not sure it solves your specific problem). On the other hand, if you
are trying to implement some kind of application functionality, time
would be well-spent redesigning the API so that it receives the
information it needs to do its job through normal means. There may also
be situations where JVMDI is the right solution, and I'm pretty certain
you could solve your problem through that direction.

I know I could also simply pass in the class object from this.getClass() in
bar, but I have dozens of these methods and would much prefer a more elegant
solution that multiple wrapper classes.

I don't know that anyone could reasonably call something "elegant" that
does what you're asking. "Ugly but tolerable given the alternatives"
might occasionally be a valid assessment...

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Sean Knapp]

Jose,

The reason for not wanting to use polymorphism is that I have well over a
dosen methods of type foo and many dozens of classes subclassing A (more
added each day), which means a heck of a lot of wrapper code. Yes, this is
part laziness, but also I found that other people subclassing A (see below)
were having to write a lot of wrapping code and were much more likely to
have bugs in their code when passing the class.

To clarify a bit more what I'm trying to accomplish: I'm essentially
modelling a number of database entries in my objects, all of which subclass
a standard class ("A"). To lookup members of a given class, A needs to know
which class is calling foo so that it can create new instances corresponding
to that class and the result set.

So in more detail, the setup looks like this:

class A {
// does lookups
protected static Object[] foo(...) {
// get calling class type
// perform query
// create objects of correct type
}

// does other tasks, but requires a couple of lookups
public void bar() {
foo(...);
}
}

class B extends A {
}

class C {
public static void main(String[] args) {
new B().bar(...);
}
}

As you can see from above, even though we are creating an instance of B, bar
is inherited from A which means that the stack trace as well as the class
context don't mention B at all.

I hope this clarifies things somewhat.

Thanks again for your help.
Regards,
Sean

The more elegant and pure OO way is to use polymorphism. So each class would
override foo() to determine what type it is. Having the supeclass determine
the type of subclass objects in my opinion is bad OO design.

class B extends A {
}

class C {
public static void main(String[] args) {
new A().bar();

This actually doesn't call anything in B. So I don't know what you are
trying to accomplish here.

}
}

 

[Sean Knapp]

Dear Chris,

In my above response to Jose, I tried to detail a bit more what I'm using
this for. Essentially, I'm modelling database entries with multiple
subclasses of "A" which does most of the work.

And yes, "Ugly but tolerable given the alternatives" does seem more
appropriate, but I'd rather factor the ugly stuff into my module (even at
the cost of increased ugliness) so the others I work with who are building
code to sit on top of this won't have to worry about any of it. =)

Thanks again for your help!
Regards,
Sean

 

[Tim Jowers]

Okay, here is the setup:

Class A has a static method foo, and a normal (non-static) method bar. foo
is called by bar. In foo, I need to find the actual class of the object that
just called me.

The tricky part is this: Class A has dozens of sub-classes, all of which use
the method bar, but never overide it.

The code looks like this:

class A {
public void bar() {
foo();
}

static public void foo() {
// Find calling class type
}
}

class B extends A {
}

class C {
public static void main(String[] args) {
new A().bar();
}
}

I know about the SecurityManager.getClassContext() trick which works great,
except for this case, since class B never shows up on the stack trace
because it's superclass method is called.

I know I could also simply pass in the class object from this.getClass() in
bar, but I have dozens of these methods and would much prefer a more elegant
solution that multiple wrapper classes.

As far as I can figure, it seems I need to somehow get the corresponding
objects to these classes found on the stack in order to use the getClass()
method, but am completely stuck as how to do this.

If anybody has any insight into this, please let me know, you'll make my
month!

Thank you in advance!
Regards,
Sean Knapp

Sean, what does the keyword "this" refer to?

 

[Sean Knapp]

Sean, what does the keyword "this" refer to?
Tim, in what context? You can't refer to "this" in a static, so I'm assuming
you mean inside of "bar", but doesn't get me anywhere since would still have
to pass through a variable unless I'm missing something... (If I am, please
let me know.)
Thanks for your help!
Regards,
Sean

"Sean Knapp" <[email protected]> wrote in message

Okay, here is the setup:

Class A has a static method foo, and a normal (non-static) method bar. foo
is called by bar. In foo, I need to find the actual class of the object that
just called me.

The tricky part is this: Class A has dozens of sub-classes, all of which use
the method bar, but never overide it.

The code looks like this:

class A {
public void bar() {
foo();
}

static public void foo() {
// Find calling class type
}
}

class B extends A {
}

class C {
public static void main(String[] args) {
new A().bar();
}
}

I know about the SecurityManager.getClassContext() trick which works great,
except for this case, since class B never shows up on the stack trace
because it's superclass method is called.

I know I could also simply pass in the class object from this.getClass() in
bar, but I have dozens of these methods and would much prefer a more elegant
solution that multiple wrapper classes.

As far as I can figure, it seems I need to somehow get the corresponding
objects to these classes found on the stack in order to use the getClass()
method, but am completely stuck as how to do this.

If anybody has any insight into this, please let me know, you'll make my
month!

Thank you in advance!
Regards,
Sean Knapp

Sean, what does the keyword "this" refer to?

 

[Jared Dykstra]

Jose,

The reason for not wanting to use polymorphism is that I have well over a
dosen methods of type foo and many dozens of classes subclassing A (more
added each day), which means a heck of a lot of wrapper code. Yes, this is
part laziness, but also I found that other people subclassing A (see below)
were having to write a lot of wrapping code and were much more likely to
have bugs in their code when passing the class.

To clarify a bit more what I'm trying to accomplish: I'm essentially
modelling a number of database entries in my objects, all of which subclass
a standard class ("A"). To lookup members of a given class, A needs to know
which class is calling foo so that it can create new instances corresponding
to that class and the result set.

You can use "this" in conjunction with the "instanceof" operator to
determine what kind of object you're dealing with. However, why you
would want to do this is still beyond me. There isn't much point
doing object-oriented programming if you're determined to manually
break things down by writing an uber-method in the super class that
takes different actions based on which subclass instance this happens
to be.

Each subclass should have a consistent--albeit polymorphic--API so you
can invoke the same method on each of the child objects without caring
which one is which. Define the interface via abstract methods in the
super class, or have the classes implement an interface which you
define.

If you have a lot of common functionality in the child classes, write
some protected functions in the parent to handle things like reading
and committing a record to the database. The child methods can call
these, thereby reducing duplication.

There are a lot of good books and other references available covering
object oriented design.