I've recently started working on a Java Project that was done many years ago and I'm trying to understand the code as much as I can (considering I'm somewhat of a beginner trying to evolve).
Here's my doubt:
I have two classes, let's say it's ClassA and ClassB that don't extend one another.
In ClassA there's a main method that runs the following code:
Thread object = new Thread(ClassB);
object.start();
From my understanding of threads, this should call a run() method on ClassB.
However the most important method on ClassB is a doMain() method and there is no run().
How do I know if doMain() is actually the method being called?
Thanks for the help :)
P.S. This is an example code, the real code is 1000x more complex and maybe there are nuances that I'm not getting, but any clues on what to do would be great.
There is two constructors for Thread you must be using here
Thread object = new Thread(classB);
Either classB is a String or Runnable. There is no other options which will compile. Assuming it is not a String, and it is a Runnable it must have a run() method or it won't compile (or if its an abstract class you can't create an instance)
In short, you have a run() method.
This is an example code, the real code is 1000x more complex and maybe there are nuances that I'm not getting, but any clues on what to do would be great.
The simplest way to prove this is to check the call hierarchy of doMain() in your IDE or add a breakpoint on this line and run your code in your debugger.
The method Thread.start always calls the run method, it's stated explicitly in the documentation: Thread#start().
Perhaps that your class with the doMain method inherits some other class, where the doMain method is abstract and the run method, defined in the same parent class, calls it?
Related
When I searched on the internet about extending the Thread class, all the examples I came across had overridden the run() method. I have also extended the Thread class in my program but I haven't defined the run() method. It's just another class (I'll refer to it as MyClass), which extends Thread class, with a constructor and a few methods defined by me. However, I'm puzzled because I have created an object of MyClass in the Main class and have called the start() method using that object in main() method. And it still works.
My question is whether the run() method is implicitly defined by the Java compiler, like the default constructor, or is it simply not required to be overridden when extending the Thread class?
No, the run() method is not implicitly defined by the Java compiler. It is explicitly defined by the Thread class.
If this thread was constructed using a separate Runnable run object, then that Runnable object's run method is called; otherwise, this method does nothing and returns.
It is not abstract, so it does not need to be overridden. There is nothing special about the run method here.
Because you're extending Thread and not supplying a separate Runnable, your class inherits the run method; run runs and does nothing.
Because it does nothing, it's not very useful. Usually you want to do something in your Thread, so normally when creating a Thread this way, run is overridden to do something useful.
Let say I have:
class Superclass {
//fields...
methodA() {...}
methodB() {...}
...
}
class Subclass extends Superclass {
//fields...
methodA() {
// Here I need to call methods A and B from superclass:
// For this, I can use supper
super.methodA();
super.methodB();
// Or I have to instantiate the superclass and use the instance
Superclass superclass = new Superclass();
superclass.methodA();
superclass.methodB();
}
It works both ways, but I want to know which is better to use. Any of these ways is a bad programming technique? I hope you give me answer and arguments.
super.methodA();
Superclass superclass = new Superclass();
superclass.methodA();
These two calls of methodA work on different instances, so they are completely different. super.methodA() executes methodA on the current instance. superclass.methodA() executes methodA on a new instance of Superclass which is not related to the current instance.
You would almost always use the first option. As for the second option, It doesn't make sense to create a new instance, call a method on that instance and then never do anything with that instance again.
It works both ways, but I want to know which is better to use.
Well that entirely depends on what you're trying to achieve. If you want to create a new, entirely independent instance, do so. But it's more common that you want to use the superclass implementation of a method you're overriding on the same instance that the overridden method is currently executing on in which case you would use super.methodA().
In my experience, super is most commonly used when overriding a method to do some subclass-specific work, call the superclass implementation, then do some more superclass-specific work. For example:
#Override public void add(Foo foo) {
doSomeSubclassSpecificValidation(foo);
super.add(foo);
doSomeSubclassSpecificBookKeeping();
}
In other words, even though you're overriding the method, you still want the "normal" behaviour - you just want some extra code to run as well. Or sometimes you want to run the superclass code conditionally, e.g. only if the input meets a certain criterion.
It's totally different.
super.methodA() will call methodA() in the left circle, while creating a new superclass and calling that methodA() will first create the right circle, and then call methods from it.
With above answers, you must have understood that basically you are calling same method of same class but on two different objects so it all depends as what you are trying to achieve ( On which object you plan to call those methods ). As you know, call to same methods of same class but on different instances are not the same. "super" object is parent of "this" object and that super object was created implicitly when you instantiated Subclass so as per your example code, both are NOT SAME but for simple cases,output might be same. Go one more level up and see if it looks different to you from client code ( try writing calling code of Subclass ).
So, I started using interfaces in Java a while ago. I have already created one, and I have a class, that implements that interface.
So this is the interface itself:
And this is the class that implements the Actor interface:
But, as you can see in the first picture, no methods are used, ecxept for create(). The most strange thing is that everything works absolutely fine! Only these underlined words freak me out a bit)
Your methods are never actually used. This is IntelliJ's way of highlighting dead code. Until you actually instantiate an Actor and call the method (see code sample below), it will appear as unused.
Actor actor = new Balls();
actor.createBody();
There is nothing wrong with these warnings: the IDE tells you that you could delete the underlined methods from the interface, because there is no code in your solution that would call these methods through the specific interface.
In top-down development, most interfaces start off looking like this: you start with an interface that has a lot of methods that nobody calls, and then the number of the unused methods goes down as you start using other operations from the interface. Eventually the number of unused methods goes down to zero, because your code starts making use of all interface methods that you define (or you delete the unused methods from your interface).
By default all methods in interface are abstract. That means they cannot have any definition. If everything runs and you have underlines, these are probably warnings. You can view more information by placing your cursor on underlined text (happens in Eclipse IDE). When you implement the interface you have to override all the methods present in interface, which you have done otherwise you would have got compile time error.
You have actually implemented/ used all methods of interface. Notice the curly brackets after method definitions in your class Balls. You just haven't written any code in them.
Read more about interfaces and you'll get a clearer picture.
I am going through Hello Android (Android PDF/tutorial) and have now seen this syntax a couple of times. Can someone please explain to me what Java syntax is used when run Runnable is defined?
private class AndroidBridge {
public void callAndroid(final String arg) { // must be final
handler.post(new Runnable() {
public void run() {
Log.d(TAG, "callAndroid(" + arg + ")" );
textView.setText(arg);
}
...
Is the code defining a Runnable object and overriding it's run method?
As Dave Newton indicated, this is an anonymous inner class implementing the Runnable interface.
As to why one would want to use this, it could be thought of as syntactic sugar of sorts. You'll notice that in your example, the code in run() has access to the same scope as where the anonymous inner class itself is defined.
This simplifies access to those members, as if you defined the class externally, you'd have to pass in a reference to any object whose members you wanted to invoke/use.
In fact, IIRC, this is actually what happens when Java compiles the anonymous inner class; if there are references to the outer containing class, the compiler will create a constructor that passes in a reference to the outer containing class.
The .post method expects a Runnable object, which in your code sample is declared anonymously and passed as the argument.
That will start a new thread for some long-running process.
The thread constructor needs a Runnable object, which has a run method that's called when the thread is ready.
When many Java apps start, all of the operations pile up on one thread, including the UI. I mainly use threads to avoid freezing up the UI if I'm doing something "heavy".
You've seen this happen when you click "execute" or something, and the UI suddenly is less than responsive. This is because the current thread doesn't have enough resources to build the UI and do whatever "execute" is asking.
So, sometimes that's done elsewhere, on a different thread, which needs a Runnable object.
It's worth noting that multithreading (where you make more than one thread on purpose) is notoriously difficult to work with, for debugging reasons mostly, IMO. But it is a useful tool, of course.
The code is defining an anonymous inner class that implements the Runnable interface, and implementing the run method to perform the appropriate actions.
I am trying to create an R function that taps into my JAVA code.
I have an abstract class, let's say StudentGroup, that has abstract methods, and one method getAppropriateStudentGroup() which returns (based on config) a class which extends StudentGroup. This allows calling classes to behave the same regardless of which StudentGroups is actually appropriate.
How can I use rJava to call getAppropriateStudentGroup()?
How can I call the methods on the returned class?
Thank you!
Java won't let you call an instance method unless you first have an instance. Naturally, you can't instantiate an abstract class, so, to the best of my knowledge, you'll have to declare getAppropriateStudentGroup() static and call it like so: StudentGroup.getAppropriateStudentGroup().
I'm assuming you actually pass some parameters to getAppropriateStudentGroup() or you'll always get the same.
Option B, I misunderstood you, and you actually do have instances of something that extends the abstract class StudentGroup, in which case you should be able to call that method on the object without problems.
I think something's a bit confused in your question or my answer, please write back ;)