We Keep Coding

Why is Thread not an abstract class and start() not final?

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.

Java, what do you call this? and why )};

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.

questions on implementing Runnable [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java: “implements Runnable” vs. “extends Thread”
I have two questions about multithreaded programming. I read a few answers on the internet, but still I can't find a satisfying answer.
Implementing the Runnable is preferred over extending the thread class. Why?
How is it that we are able to get away with overriding just the run() method?
According to 'The Complete Reference to Java' by Herbert Schildt, If we are not overriding any methods of Thread class other than run(), it's better we implement Runnable.
My 2nd question might sound a bit silly, but I seem to be missing something and I'm not sure about how the whole thing works.

1: Implementing the Runnable is preferred over extending the thread class. why?
Because it allows your class to extend another class if it wants to instead of being forced to extend Thread.
2: How is it that we are able to get away with over-ridding just the run() method?
You can certainly override other methods but the Thread object will call the run() method when the thread is started. That's how it works. The default Thread.run() method is:
public void run() {
if (target != null) {
target.run();
}
}
If you call the Thread constructor with a Runnable then that is what the target is set to. If you instead extend Thread and #Override the run() method then that is the method that will be called when the thread object is started.
That's how the Thread class works.
2: How is it that we are able to get away with over-ridding just the run() method?
You may have misspoke here and were instead asking why we only need to implement the run() method in Runnable().
Runnable is an interface with a single run() method that you must implement.
Thread is a concrete class that you are extending. You can override any methods in a concrete class unless the class is final or the method is final.
Make sure you use proper Java terminology and don't mixup implement and override.

Three fundamentals before you delve deeper.
A class can only extend one class.
A class can implement any number of interfaces.
An interface can extend any number of interfaces.
Additionally, an abstract class is a class. So it behaves like a class and you can't implement it. You only extend it.

There are a number of traps which can occur if you extend Thread which you don't get with implementing Runnable.
public static String getName() {
return "My Test Application";
}
public static void stop() {
System.out.println("Shutting down");
}
public static void main(String... args) {
new Thread() {
#Override
public void run() {
System.out.println(getName());
stop();
}
}.run();
System.out.println("Bye now.");
}
prints
Thread-0
Bye now.
See how many bugs you can spot.

Unnecessary inheritance is generally a bad idea. You might hear "prefer composition over inheritance" often enough. I'm sure google can pull up enough links for you. The general issue is that inheritance bring tight, unnecessary coupling between classes.
Same goes for GUI components, btw.

How does this threadExample work?

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.

Passing this to a constructor

In most of my java applications, I have a Controller (Logic) class and a GUI class. I usually need the Logic class to call methods on the GUI class, and vice versa. Now, when the Logic constructs the GUI, I pass a reference to "this" in the constructor so the GUI can call methods on the Logic. Here is some example code.
public class Logic {
private int num = 2;
private final GUI gui;
public Logic(){
gui = new GUI(this);
}
public int getNum(){
return num;
}
}
public class GUI {
private final Logic logic;
public GUI(Logic logic){
this.logic = logic;
}
public void calledLater(){
int num = logic.getNum();
}
}
My question is: Is this the best OO way to create an aggregation relationship, or am I messing up my design?

In the design you've posted, there's a tight coupling between your UI and your model. This is somewhat frowned upon if building large/formal/serious/long-lived systems. There's a well known pattern of architecting UI/Model architecture known as Model-View-Controller that addresses this.
Whether or not you need to worry about going to town on making an MVC styled architecture really depends on the context of your app and your desires for it in the future. But you should read up on MVC and know that it is there.
Btw, I see in your code a "code smell": two objects, A and B, each holding a reference to each other. There is usually a more desirable way of doing things than having cyclic references. You can avoid this by having, for example, object A holding a reference to B (and perhaps even 'owning' it), and B pushing data of interest to A via notifications, or the observer pattern, etc. This avoids B having to have any specific info about A, or even having to know that it exists. Voila, less coupling in your design, so you end up with more scope for code re-use, and a less brittle system that is easier to change.
An important and central design pattern in Cocoa (and Cocoa Touch) is the delegate pattern. This pattern involves using protocols (similar to interfaces in other langs like Java) to decouple the producer and consumer of information, events, etc.
I suggest reading this excellent reference from Apple about fundamental design patterns in Cocoa Touch.

Passing this to a UI class is not in itself a problem, as long as the methods of the class are not called through this, as in your example. You call getNum right in the constructor of the GUI, which should be avoided: your Logic class may not be ready to return the correct result.
One thing to note is that you couple your GUI to the Logic class, which may be too much coupling. You should consider extracting an interface from Logic, and let GUI interact only with what's intended for it:
interface DataSourceForTheGui {
int getNum();
}
class Logic implements DataSourceForTheGui {
int getNum() {
return n;
}
}
class GUI {
private readonly DataSourceForTheGui data;
public GUI(DataSourceForTheGui data) {
this.data = data;
}
public void display() {
int k = data.getNum();
}
}

Well... I'm ok with GUI holding an instance of Logic. After all, if the GUI is supposed to use the Logic object, it's going to have to access it somehow.
However, I would rather see Logic NOT construct GUI. If you really want model and view to be separate, I think that you would construct Logic somewhere, and construct GUI with the Logic object. Then, if Logic ever needs to update the GUI for whatever reason, you should have it generate an event.
In that case, Logic needs to have a list of event listeners, so that whenever it generates an event, all the event listeners are notified. The GUI then registers with Logic as a listener, and is thus able to receive all the events.
Some good classes for this are java.util.EventListener and java.util.EventObject.
But really, that's only necessary if Logic needs to communicate up to GUI asynchronously. Otherwise, just stick with Logic not constructing the GUI.

The best thing (or at least the easiest to understand) is to have the initial thing created as an outside class (called directly by the main class or the main class itself). So your code would look somewhat like this.
public class MainClass{
public static void main(String[] args){
l = new Logic();
g = new GUI(l);
l.setGUI(g);
}
public static Logic l;
public static GUI g;
}

I'd say it will work, but I'd never ever reference a GUI object from your business logic.
I'll answer with comments. What are you trying to do?
your user should instruct your GUI, and the GUI should properly instruct the Logic to do what it needs to do, and return results back to the GUI.
Few other comments:
I'd make your Logic num member a constant since it's not changing
If you're not changing your Logic object ever for your GUI, there's no reason to pass it into your constructor.
If you want to change your Logic object, I'd make a property called Logic in your GUI class so you can get access to it and change it when necessary.
If you really want to get fancy, you'd keep your Data Access Layer (business logic) in a separate library from your GUI so all of your interfaces/applications can utilize it. Then you'd import your Logic library into any interfaces that need it.