Paul Somnath

Hi Ankit,
Last to congratulate you but not the least..
Congrats buddy..
May you fly with such colors for your upcoming exams also..

Hi,
Interfaces are meant for the outside world. They should ideally contain no implementation and should only contain the method names and declarations.
Think if the methods in the interface had been private or had package access, how should the outside world know which method to implement?
That would violate the very rule of interfaces isnt it?

Cant get a more perfect score than that!
But I wish you had given the latest version.

Originally posted by Zdenek Pine:
Hi Rekha & Paul,
I thing you thing too much :-) If you compile and run the program, there is no possibility to interrupt the sleep function, because you did not programme it. Believe in yourself, believe in your ability. You are The Programmer.
:-)

What a funny post !!

Originally posted by Rekha Srinath:
Source: www.danchisholm.net

class A extends Thread { public void run() { try {sleep(10000);} catch (InterruptedException ie){} } public static void main(String[] args) { A a1 = new A(); long startTime = System.currentTimeMillis(); a1.start(); System.out.print(System.currentTimeMillis() - startTime); }}

I am not sure how c is correct, because if there is an interruption to the sleeping thread, an InterruptedException is thrown and the program halts. In such a case, the thread will run lesser than 10 seconds, and hence option c is not correct, right?

Hi Rekha,
Your reasoning is absolutely correct. The thread may be interrupted in between and the program may NOT always run for atleast 10 seconds. But if you read the question properly, it says: What are the possible results of attempting to compile and run the program?
Now this is a possibility that the program runs for full 10 seconds in the case that the thread is not interrupted.
So 'A' and 'C' are correct.

As Jesper says, pointers that do not point to anything(dangling pointers) are really painful. With automatic memory management, it is a hell lot easier to code and forget about memory considerations.

Originally posted by geet kaur:
guys why don't we have pointers in java?like c++
i have tried to understand it many a times but still confused about this..
can any one explain??

A very general explanation:
Pointers directly allow you to manipulate memory. If you are allowed to manipulate memory, then it may lead to destructive programs. Hence they are not allowed in Java for security reasons.
In C++, you can use pointers to reclaim memory and sometimes may lead to memory leak since you do it manually. In Java you have the garbage collector which does this automatically and minimizes the risk of memory leak and hence you can concentrate on the application programming rather than memory considerations/optimizations.
[ October 21, 2008: Message edited by: Paul Somnath ]

This is because the java.lang.Thread implements the Runnable interface.
Read the java docs.

Originally posted by Srinivasa Maddi:
You can probably go for Kathy Sierra. try to google you may get the pdf's.

Hi Srinivasa,
Please dont encourage things like downloading pdf's from internet. Kathy-Sierra book is not free. It is illegal to download the soft copy. Anyone who does that and caught may have their accounts deleted.
Please dont encourage piracy.

Read this thread.

Originally posted by Pradeep Balasubramanian:
Sachin Tendulkar.

if sachin has retired in 2000, it would have confirmed a place for some 100 youths in Indian Cricket Team.


That`s the truth.


[ September 24, 2008: Message edited by: Pradeep Balasubramanian ]

There can be a 100 new youths in the team, but ONLY ONE TENDULKAR in the history of cricket.

Hi Karthik,
Welcome to JavaRanch..
If you have problems replying to a post then there are two options:

1:


2:

There are some differentiations when you want to run a thread that has been extended from Thread class and one which has implemented the Runnable.
Go through this code and I guess it would be clear. For a class that implements runnable, to start the thread, we always need a runnable target.
Since the class that extends java.lang.Thread already implements runnable, we can start the thread simplpy by creating an object of the class and calling start method on it.

public class A { public static void main(String[] args) { B b = new B(); b.start(); Thread t = new Thread(b); t.start(); C c = new C(); //c.start();can't do this! Thread t1 = new Thread(c);//needs a runnable target. t1.start(); } } class B extends Thread { public void run() { System.out.println("Extending a thread.."); } } class C implements Runnable { public void run() { System.out.println("Implementing Runnable.."); } }

I am sorry about my previous post.
I was incorrect.. Non-synchronized blocks don't have any locks.

And the non-synchronized block can be concurrently accessed by other threads too when a particular thread is already accessing it.

For example when we run the following code:

public class SynchronizeTest implements Runnable { public static void main(String[] args) { SynchronizeTest obj = new SynchronizeTest(); Thread t1 = new Thread(obj); t1.start(); obj.non_sync(); SynchronizeTest obj2 = new SynchronizeTest(); obj2.non_sync(); } public void run() { sync(); } public synchronized void sync() { System.out.println("Sync: " + Thread.currentThread().getName()); non_sync(); } public void non_sync() { System.out.println("Entry Non-Sync: " + Thread.currentThread().getName()); try { System.out.println(Thread.currentThread().getName() + " going to sleep..."); Thread.sleep(5000); } catch(InterruptedException e) { } System.out.println(Thread.currentThread().getName() + " woke up!"); System.out.println("Exit Non-Sync: " + Thread.currentThread().getName()); } }

Before the sleep of main method(just a case when main executes first before Thread-0), we get this output:

Entry Non-Sync: main
main going to sleep...
Sync: Thread-0
Entry Non-Sync: Thread-0
Thread-0 going to sleep...

This shows that: while the main has entered the non-sync method and is currently executing the sleep statement and is sleeping, Thread-0 also enters the non_sync method. This is shown by the output: Entry Non-Sync: Thread-0. This clearly shows that both the main and Thread-0 are concurrently executing the same method non-sync at the same time.
Hope this clears all the confusion.
Thanks.
[ October 16, 2008: Message edited by: Paul Somnath ]

Srilatha nails it.
The output in the original post is completely undefined, since the main thread blocks on thread-a and there are not print statements after the join method.
I suggest the original poster to read up on this topic. This type of question has been discussed many many times and can be found in this forum if someone browses history threads.