Java question

[MikeF98765]

Ok so... i have a class with a static method doThing(). I want to subclass this class, and when the subclass calls the method doThing, i want it to know what class called it (the subclass).

So i have

public class BaseClass{
   public static doThing(){
      //Print name of class
   }
}

public class SubClass extends BaseClass{}

when i call SubClass.doThing(); i want it to print out blah.blah.SubClass

how can i do this? Since it's a static method, you can't get the instance taht's calling it... is there any way to do this?

To clarify: How can i tell the difference between BaseClass.doThing() and SubClass.doThing()

 

[Nemezer]

Please note that I haven't done Java in like 5 years, so it's a bit rusty.

To clarify: How can i tell the difference between BaseClass.doThing() and SubClass.doThing()

By default you can't. that is, a static method belongs to the class itself. One workaround is to simply define an argument for your static method.

public static doThing(Object caller) {
    //Print name of class
    System.out.println(caller.getClass());
}

And then, whenever you do call doThing(), you do it as followed:

doThing(this);

My personnal opinion is that you should probably rework the design, but the above workaround will do the trick.

 

[DrFreeze]

dont worry Nemezer, your java isnt that rusty

what you posted is exactly what i thought up when i read the OPs question, and would be the only way as far as i can tell, you would need a reference to the calling object.

you could always start fooling around with strings, but the this reference would be the best imho.

to the op:
is this some sort of assignment, or are you programming an actual program? you might want to reconsider your design, depending on what kind of rules you have to stick to

 

[ambientZ]

how can i do this? Since it's a static method, you can't get the instance taht's calling it... is there any way to do this?

To clarify: How can i tell the difference between BaseClass.doThing() and SubClass.doThing()

Even if it wasn't static, you wouldn't & shouldn't be able to tell what class is calling it. Redesign what you are doing if your application depends on this sort of behavior.

If this is for trivia only, or possibly debugging. You can actually do this. I believe you need to create an exception and walk the stack trace to find out who called you. At least thats the theory anyway. This is totally horrible programming and if you use it in a real app you should never write another program again.

 

[MikeF98765]

Even if it wasn't static, you wouldn't & shouldn't be able to tell what class is calling it. Redesign what you are doing if your application depends on this sort of behavior.

If this is for trivia only, or possibly debugging. You can actually do this. I believe you need to create an exception and walk the stack trace to find out who called you. At least thats the theory anyway. This is totally horrible programming and if you use it in a real app you should never write another program again.

So i've rewritten my stuff, it was more for my curiosity. I'm brand new to java and I was interested in how exactly static calls worked. Your solution, though obviously awful, was interesting, thanks.

This is very much a real project for work, and it ended up being one of those "throw everything away and rewrite a much better version in 10 minutes" issues. Thanks guys.

 

[ambientZ]

its one of those things to keep in the very back of your toolbox out of sight. There may come a time when it saves your bacon, but most people should never have to use it. The programmatic .getStackTrace came in with java1.4, and the api docs warn not all jvm's may have completely accurate info in it. It beats parsing a printed stack trace in code which is what i've heard people used to do.

I haven't ever used it myself. I just make my code unreadable with reflection instead

 

[DrFreeze]

Even if it wasn't static, you wouldn't & shouldn't be able to tell what class is calling it. Redesign what you are doing if your application depends on this sort of behavior.

If this is for trivia only, or possibly debugging. You can actually do this. I believe you need to create an exception and walk the stack trace to find out who called you. At least thats the theory anyway. This is totally horrible programming and if you use it in a real app you should never write another program again.

i briefly considered bringing up the whole exception/stacktrace thing, but i never tried that, so i dont know if it would be possible to throw and catch and exception, and then proces the stacktrace without problems

might try this out tomorrow, cant be bothered firing up netbeans right now.

as for it being horrible, meh, its quite inventive, but a total abuse of the whole exception mechanism, i wouldnt call it horrible, but anyone who actually uses that in production code should probably do some studying

 

[ambientZ]

i briefly considered bringing up the whole exception/stacktrace thing, but i never tried that, so i dont know if it would be possible to throw and catch and exception, and then proces the stacktrace without problems

might try this out tomorrow, cant be bothered firing up netbeans right now.

as for it being horrible, meh, its quite inventive, but a total abuse of the whole exception mechanism, i wouldnt call it horrible, but anyone who actually uses that in production code should probably do some studying

I don't think you even need to throw the exception, just create one and access the stack trace on it. Testing on java1.6/win32 looks like you don't. If for some reason the stack trace wasn't filled in, there is a method to cause the trace to be filled in before you access it.