I wanted to write multiple threads under one class and found one way of doing it.
public class ThreadExample {
public static void main(String[] arg)
{
Thread one = new Thread() {
public void run() {
try {
Thread.sleep(2000);
} catch(InterruptedException e) {
e.printStackTrace();
}
System.out.println("One");
}
};
Thread two = new Thread() {
public void run() {
System.out.println("Two");
}
};
one.start();
two.start();
}
}
Thing I don't get here is, I am neither extending the Thread class nor am I implementing the Runnable interface. How do I understand this?
And If the answer is, "I am just creating the object of the Thread class and using it, then why not always do this rather than doing the things mentioned above?
Technically, what you are doing is extending Thread. You are extending it on the fly with something called an anonymous inner class - to learn more about what that is, start here and read this page plus the next two.
What this means is you are creating temporary inline subclasses that have no name, and whose definitions survive only until the method finishes. Why do this rather than create a named subclass of Thread or implementation of Runnable? It makes sense when the body of run() is as simple as the examples above - there's less typing and fewer .java files to keep track of. One-off simple tasks like these are good candidates for anonymous inner class extension of Thread. For major program logic, you probably want to do a full named class implementation in a separate file.
In addition, once you've gotten good experience with Thread, I would encourage you to check out the java.util.concurrent package.
Ah, but you are extending the Thread class... anonymously.
When using the new Class() {} syntax, you are creating an anonymous class that is a sub-class (ie effectively extends) of the named class.
In this case, you have overridden the Thread.run() method.
This approach, while it works, it not considered "good design", because you are extending Thread, but you are not creating a new kind of Thread. It is better to pass a Runnable into the constructor:
new Thread( new Runnable() {
public void run() {
// do something
}
}).start();
Bohemian answered your first question so I'll answer your second one: "I am just creating the object of the Thread class and using it, then why not always do this rather than doing the things mentioned above?"
If you always do it the way you did in your question then you can't separate the logic that performs the task from the way the task is run. Implementing runnable lets you bundle the logic that performs your task separately from the code that manages how your task is run.
If you use runnables you are able to run your task in a new thread, run your task in the calling thread, run your task after some delay or run it in some other fashion without modifying the code in the runnable.
When working with threads you'll generally want to use an ExecutorService instead of using the thread class directly. Executor services provide facilities for limiting the numbers of threads, handling failed executions, determining when a runnable completes, getting return values from tasks run in other threads and so on.
Related
Why was the Thread class implemented as a regular class and not an abstract class with run() method being abstract.
Will it possibly introduce any problems? Or does it have any use in being this way?
Also, the Thread.start() method is supposed to be a very specific method whose functionality cannot be implemented by any other class (If I am not wrong). And hence I guess the final keyword would be apt for this more than any other method.
But I am able to override this method and use it as I like,
public class Test extends Thread {
public static void main (String... args) {
Thread test = new Test();
test.start();
}
#Override
public void run() {
System.out.println("New thread started...");
}
#Override
public void start() {
System.out.println("Did anyone tell you I will spawn a new thread??");
}
}
It obviously only printed,
Did anyone tell you I will spawn a new thread??
Is there any use in overriding other than confusing the engineer replacing you?
If not, why was the method not declared final in Thread class?
You can of course choose to shoot yourself in the foot, but that doesn't mean you must.
Why was the Thread class implemented as a regular class and not an abstract class with run() method being abstract.
Because the recommended way to create a start a thread is not to subclass Thread. The recommended way is to define a Runnable, and pass it as argument to the Thread constructor:
Runnable r = new Runnable() {
#Override
public void run() {
...
}
};
Thread t = new Thread(r);
t.start();
And hence I guess the final keyword would be apt for this more than any other method.
Yes and no. You can't replace the implementation of start() by your own implementation, but you can do additional things in start() if you want:
#Override
public void start() {
System.out.println("Did anyone tell you I will spawn a new thread??");
super.start();
}
That said, if Java was redesigned from scratch today, there is a good chance the design would be different. Remember that this class dates from Java 1.0, and is still backward-compatible.
Why was the Thread class implemented as a regular class and not an
abstract class with run() method being abstract.
This question actually boils down to the fact that you should always prefer composition over inheritance.
If the Thread class was declared as abstract, the language would have to provide another class that extended from it which programmers could use to create a Thread. Your question would then be about why this class that extends from Thread is not abstract. If the language did not provide another class that extends from Thread, programmers would have to create their own class that extends from Thread and override the run() method.
If not, why was the method not declared final in Thread class??
The only possible explanation I can give is that the developers of the language saw some use-cases for overriding start when the class was introduced to the JDK. The first version of Java that I used was 1.5 and I personally have not come across a use-case where I found the need to override start. As JB Nizet stated in his answer
if Java was redesigned from scratch today, there is a good chance the design would be different
Why is Thread.start() not final?
Are you sure you would never want to override it?
Class MyThreadFactory implements ThreadFactory {
#Override
public Thread newThread(Runnable r) {
return new Thread(r) {
#Override
public void start() {
LOGGER.info("Starting thread " + this);
super.start();
}
};
}
}
I feel a few calirifcations should be posted for the answers :
"Are you sure you would never want to override it?"
No ! I would not. Thats like saying, "Are you sure , you want to declare this variable private?" Because if I could declare any variable I use as public without fearing that other developers may mess my design logic, coding would be a breeze. One of the most important purpose of OOPS concepts of Scope, abstraction, polymorphism, Error handling etc is to communicate to other developers the design and intentions behind your code.As pointed out in the question, when you override start method, nobody is forcing you to use super.start(). #Codebender wrote a start method for a thread without using super.start() and compiler never complained. So he is free to break the whole mechanism of Threading and compiler is suppose to just let it pass? Thread's start method ensures that run method is called and execute at the right time ! It is critical to the very concept of Threading. I would be more than happy to be corrected, if I missed something here.
2.
Because the recommended way to create a start a thread is not to
subclass Thread.
OK, if codebender is allowed by design, to sublass Thread and mess up the start method, By that logic, it is the design shooting itself in the foot.
By another statement made,(which I agree with completely) , Runnable is the recommended way. Then why do we allow Thread class at all to instantiate the thread at all with no restrictions? This is followed by :
You can't replace the implementation of start() by your own
implementation,
That actually supports codebender's claim that start method should be final when you say that.. ^
The one point, that's valid, is mentioned already as a side note, but is the actual answer to this question
"Backward compatibility".
In fact, improvements were even going on as late as JDK 5.0 , when they incorporated many major additions and clarifications to the Java concurrency model. We want backward compatibility to be supported all the way and thats why Thread class is still exactly as it was before, even though Runnable interface is the recommended way nowadays.
Again, I would be more than happy to be corrected, if I missed something.
Is it a kind of bad design to use local Thread field in Runnable implemented class like this:
public class TestingThread implements Runnable {
Thread t;
public TestingThread() {
t = new Thread(this, "Testing thread");
}
public void start()
{
t.start();
}
...
Although this kind of question is obviously opinionated, I will tell you why I think that this is a design flaw. (Actually, I provoked this question, so maybe I should answer.)
A Runnable is an object holding the code that will (or should) be executed within a thread. The documentation explains it this way:
The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread.
The main idea behind the Runnable interface is to separate the executable code from the means of executing it. There are several possibilities of running such code in an own thread.
One of those possibilities is the Thread class. From its documentation:
There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread. This subclass should override the run method of class Thread. An instance of the subclass can then be allocated and started. [...] The other way to create a thread is to declare a class that implements the Runnable interface. That class then implements the run method. An instance of the class can then be allocated, passed as an argument when creating Thread, and started.
In my opinion, you always should do the latter. Define implementations of the Runnable interface, pass instances of them to the constructor of a Thread, then start the thread. Example:
class MyRunnable implements Runnable { ... }
void runMyCodeInOwnThread() {
Runnable runnable = new MyRunnable();
Thread thread = new Thread(runnable);
thread.start();
}
The other way of executing a Runnable in a thread is an Executor, although you most likely will use an ExecutorService (actually a subtype of Executor). The utility class Executors will most likely be used for retrieving an executor service. Example:
class MyRunnable implements Runnable { ... }
void runMyCodeInOwnThread() {
Runnable runnable = new MyRunnable();
ExecutorService executor = Executors.newSingleThreadExecutor();
Future<?> future = executor.submit(runnable); // or simply "executor.execut(runnable);"
}
If you don't tangle your runnable with the means of how to execute it, you are free to use either mechanism or change it in the future when requirements advance.
However, as I looked through the classes' documentations, I also saw the same mechanism in the examples. Still, I think this is not a good design.
Keeping or using a local thread variable inside another thread class is matter of choice.But personally from my knowledge its not a good design,until you have specific requirement to do so and use that local thread variable inside your thread class.You hardly needs this type of requirement in real life scenario.Hope it helps you !
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.
In my project I have a game class which is called by a client class. At the moment the game class writes a path to a file and the client class will read from this file and clear the contents. I am getting too many conflicts with access here so want to use another class as the method for storing the path data. I want to know, however, if there will still be a problem, or what the outcome will be if the game class tries to call the method in the storage class to write whilst the client class at the same instant calls the method in the storage class to read and clear.
Sounds like you need to think about threading and synchronization. I'd recommend reading "Java Concurrency in Practice".
In presence of multiple threads, your classes have to be thread safe. One way of achieving this is to make the concurrently accessed methods synchronized.
Here is an example to get you started:
public class Test {
public static void main(String[] args) throws Exception {
new Thread() { public void run() { Test.method(); }}.start();
new Thread() { public void run() { Test.method(); }}.start();
}
public synchronized static void method() {
System.out.println("hello ");
try {
Thread.sleep(1000);
} catch (InterruptedException e) {}
System.out.println("world");
}
}
Without the synchronized modifier, this program would have printed
hello
hello
world
world
With the synchronized keyword, only one thread at a time can call method, thus the program prints
hello
world
hello
world
I'm assuming your two classes are running in separate threads, so they might access the third class at the same time. The access to the resource they are reading and writing needs to be synchronized (mutexed). Java has the keyword "synchronized", which can be used in multiple ways to prevent concurrent modifications and such, see here and here for details
The theoretically correct answer is: "anything can happen".
The two calls can run one after the other or interleaved with each other, the results are unpredictable and potentially disastrous.
That's why Java offers you several ways of dealing with it.
The simplest (sounding) way is to write your methods threadsafe. In practice this usually means that you should only use local variables and must not modify the objects that are passed to you as parameters. (No side-effects.) Many methods automatically fall into this category, in which case you don't have to worry about concurrency.
If your method cannot be made threadsafe, you need to handle concurrent calls somehow. synchronized blocks are the most often used constructs but in some cases, a volatile field or using Atomic* classes will suffice. But this subject is way too heavy to be covered in a single answer, so I suggest you read the concurrency tutorial.
Having a problem here, I have been learning about threading in java i understand if you are extending a thread you would create a thread in the main as follows.
Card thread1 = new Card("Ace");
This would be coming from a class called thread with a constructor
public thread(String n);
But i have given the constructor with a multiple argument:
public Person(int PersonID, Direction direction, StairLock stairLock)
And asked to create a thread for each of 4 people with two people going UP and 2 going DOWN and a lock for the stair, im unsure how to do this any help or direction would be helpful
There are multiple issues with your question.
Any class which extends thread, in its constructor, can call super(String) to pass the thread name to the superclass thread. So in your constructor for Person, you can call this constructor for Thread immediately with the name you want for the thread. It is a good practice to always name your threads for debugging identification.
You refer to the class thread, but you should know this is different from Thread. Classes in Java should always start with uppercase letters. If you made your own thread class, you are not actually making a thread.
I'm not sure why a Card or a Person class should need to extend Thread. Unless you're just picking random names for this example, these classes sound more like data objects rather than threads. If this is the case, you might want to consider having a separate class be the Thread which handles the movement up and down the stairs, and give each thread its own Person class instance to handle.
Given all of this, if you were asked to make a thread for each Person to handle its movement, I would recommend creating a separate class from Person to do this. Either extend Thread or implement Runnable and take a Person in the constructor. Both classes use a .run() method that you have to implement to do the workload of the thread. With a Thread, you can just instantiate it and call .start(). With a Runnable, you have to create a new Thread and pass the Runnable as an argument to the constructor, then call .start() on the Thread.
Many people prefer to use the Runnable approach, but the results are pretty much the same either way. If you're handling threads, you should be familiar with both ways of doing it.
Thread vs Runnable
You should probably not extend thread.
Implement Runnable and start a new thread with your Runnable.
Reason: If you extend Thread, you interfere with working infrastructure code. You should only do that if you need to change how things work. In 90% of cases, you only need to specify what needs to be executed, not how. That's why the Runnable approach is more elegant: you separate the what from the how.
From the Runnable docs:
In most cases, the Runnable interface
should be used if you are only
planning to override the run() method
and no other Thread methods. This is
important because classes should not
be subclassed unless the programmer
intends on modifying or enhancing the
fundamental behavior of the class.
Sample Code
Try something like this:
public void startThread(final int personID,
final Direction direction,
final StairLock stairLock){
new Thread(new Runnable(){
#Override
public void run(){
System.out.println("Person " + personID + " runs in direction "
+ direction
+ "and I have no idea what a Stairlock is, but here it is "
+ stairLock);
}
}).start();
}
OOP Design
In General, be careful how you model objects.
If I understand you right, Card is-a Thread in your concept. That's awful! A Card can have-a thread, but it should never be one!
In good OOP design, a class has exactly one purpose, this is called Cohesion. Also, different kinds of functionality should be loosely coupled, i.e. Domain Classes should never contain infrastructure code.
Firstly, welcome to the world of learning Threads. Sure, you can extend Thread, just call the constructors with right signatures. Or, you could implement the Runnable interface, too. The two implements below (A and B) are equivalent in terms of functionality. Now, Mr. Floyd told us not to extend Thread. Lets explore why (I do not disagree, just trying to help you understand a design issue in Java).
Class extension is Java's implementation of inheritance, a basic OO paradigm. When you extend Thread directly, you are saying "My class (Person) 'is a' Thread", and that is perfectly acceptable. The reason most people do not extend Thread in this manner is Java's lack of multiple inheritance. Now don't quote me on that, I have no statistics to back it up and it is also possible that their IDE's do not allow it or supervisors do not like it. But here is the issue:
Without debating whether multiple inheritance is good or bad, we can see that it is not there and safely assume that it aint gonna be there in the near future. This means that if your class extends Thread, it cannot extend anything else. This puts you in a bind. However, java allows your class to implement multiple interfaces, and Runnable can be just one of them. This gives you more degrees of freedom as the object designer, as you can pick from (extend) a variety of well established classes to suit your design goals and still have the multithreading functionality.
Hope that helps. Regards, - M.S.
// A
public class Person extends Thread {
public Person (int PersonID, Direction direction, StairLock stairLock) {
super();
// Other stuff for constructor
}
public void run () {
// Whatever you want to do with the thread
}
public static void main (String[] args) {
for (int i = 0 ; i < names.length ; i++) {
Person ace = new Person (names[i], xxx, xxx);
ace.start();
}
}
}
////////////////////////////////////////////////////////////
// B
public class Person implements Runnable {
public Person (int PersonID, Direction direction, StairLock stairLock) {
// Other stuff for constructor
}
public void run () {
// Whatever you want to do with the thread
}
public static void main (String[] args) {
for (int i = 0 ; i < names.length ; i++) {
Person ace = new Person (names[i], xxx, xxx);
new Thread (ace).start();
}
}
}