this.wait( sleep );

[P.Hill]

Apparently this is NOT how I tell the VM that I
won't to sleep. If is not how do I?

-Paul

 

[Ricardo]

Apparently this is NOT how I tell the VM that I
won't to sleep. If is not how do I?

-Paul

How about:

Thread.currentThread().sleep();

 

[Matt Parker]

Apparently this is NOT how I tell the VM that I
won't to sleep. If is not how do I?

-Paul

This will put the currently executing thread to sleep -
Thread.currentThread().sleep(time-in-milliseconds)

Of course the bigger question is why do you want to do this, which you
haven't stated...

Matt

 

[Jezuch]

U¿ytkownik Ricardo napisa³:

Thread.currentThread().sleep();

WARNING!
This is bogus.
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Thread.html#sleep(long)
Thread.sleep() is *static*

 

[Tony Morris]

This will put the currently executing thread to sleep -

Thread.currentThread().sleep(time-in-milliseconds)

As already mentioned in this thread (no pun intended), this is NOT
recommended.
In fact, referencing any static member non-statically is very poor form.
The language designers overlooked this behaviour, and if we could turn back
time, the compiler wouldn't allow it.

Thread.sleep(long) is the only recommended way to achieve what you are
trying.
Be aware that calling this method does cause the current thread to
recommence execution after the specified number of milliseconds. It cause
the current thread to sleep for the specified number of milliseconds. This
is a subtle, but significant distinction.
The thread will begin execution after AT LEAST the specified number of
milliseconds. After this time, the thread enters the ready state, and the
scheduler will decide when the thread recommenced execution (which may be
after some time period).

It is for this reason, that the precision of specifying the number of
nanoseconds to the Thread.sleep method is questionable; the question arises
regarding why such precision is necessary if the thread will recommence
execution after at least that specified time.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Matt Parker]

U?ytkownik Ricardo napisa?:

WARNING!
This is bogus.
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Thread.html#sleep(long)
Thread.sleep() is *static*

Wrong, it's not bogus. It is exactly how you make the currently executing
thread go to sleep...

Matt

 

[Matt Parker]

U?ytkownik Ricardo napisa?:

WARNING!
This is bogus.
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Thread.html#sleep(long)
Thread.sleep() is *static*

Wrong, it's not bogus. It is exactly how you make the currently executing
thread go to sleep...

Matt

 

[Carl Howells]

Wrong, it's not bogus. It is exactly how you make the currently executing
thread go to sleep...

Perhaps bogus is too strong a word. It is, however, of such bad style
that it should never be done that way.

You should never call a static method on an instance. It just makes it
harder to see what's going on. People (like you seem to) might even
think that using the instance is necessary, which can lead to really bad
coding practices.

Just call write:

Thread.sleep(500);

if you want a half-second pause.. Getting an instance just makes things
more confusing and (in a very minor way) less efficient.

 

[Matt Parker]

As already mentioned in this thread (no pun intended), this is NOT
recommended.
In fact, referencing any static member non-statically is very poor form.
The language designers overlooked this behaviour, and if we could turn
back time, the compiler wouldn't allow it.

Thread.sleep(long) is the only recommended way to achieve what you are
trying.

By stating Thread.sleep(time-in-milliseconds) I implied the use of
Thread.sleep(long). I certainly wouldn't use this in anything other than
something trivial like animation in an applet though. But the OP didn't
state what they wanted, they merely asked how to make a Thread object
sleep, and my answer was correct in this regard.

In a real (read non-trivial) application I would synchronize against a
locking object/method until the state that was required was able to
..notify() the lock, rather than rely on the vaguaries of timing.

Matt

 

[Matt Parker]

Perhaps bogus is too strong a word. It is, however, of such bad style
that it should never be done that way.

You should never call a static method on an instance. It just makes it
harder to see what's going on. People (like you seem to) might even
think that using the instance is necessary, which can lead to really bad
coding practices.

Just call write:

Thread.sleep(500);

if you want a half-second pause.. Getting an instance just makes things
more confusing and (in a very minor way) less efficient.

You are right of course. I just looked at some of my old code for
implementing an animation wait (I never use Thread.sleep() for anything
else and I haven't done it for a long time) and I see I did it this way:-

while(true)
{
repaint();
GameManager.getInstance().updateManagers();

Thread.yield();
try
{
Thread.sleep(REFRESH_RATE);
}
catch (Exception e)
{
System.out.println("Exception in run() : " + e.getMessage());
e.printStackTrace();
}
}

Oh well, guess I should engage brain before posting...

Matt

 

[Ricardo]

Perhaps bogus is too strong a word. It is, however, of such bad style
that it should never be done that way.

You should never call a static method on an instance. It just makes it
harder to see what's going on. People (like you seem to) might even
think that using the instance is necessary, which can lead to really bad
coding practices.

Just call write:

Thread.sleep(500);

if you want a half-second pause.. Getting an instance just makes things
more confusing and (in a very minor way) less efficient.

There is no question about the fact that sleep(long) is a static method
of class Thread, and which style should be implemented to call it
[Thread.sleep(interval) in specific, and not static methods in general]
has been debated way too many times. I can't find the reference now,
but there was a time when Sun documentations insisted on giving a
preference to Thread.currentThread().sleep(interval), and this style has
been very widely used, as many make the argument that this a very
critical self documenting code that alerts the novice that yes, it is
the current thread that is been paused.

To make this more interesting, examine the following document from the
1.4.2 documentations:

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Note the different calls to sleep().

 

[Tony Morris]

By stating Thread.sleep(time-in-milliseconds) I implied the use of
Thread.sleep(long). I certainly wouldn't use this in anything other than
something trivial like animation in an applet though. But the OP didn't
state what they wanted, they merely asked how to make a Thread object
sleep, and my answer was correct in this regard.

In a real (read non-trivial) application I would synchronize against a
locking object/method until the state that was required was able to
.notify() the lock, rather than rely on the vaguaries of timing.

Matt

Thread.currentThread().sleep(time-in-milliseconds)

That is beside the point.
Calling sleep using a Thread reference is bad practice.
It should always be called statically (although it is not compile-time
enforced).

It is not possible to cause any arbitrary thread to enter sleep state, only
the currently executing thread, hence the sleep method is static and should
be referenced as such.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Tony Morris]

Thread.sleep(500);

if you want a half-second pause.. .

"if you want AT LEAST a half-second pause."
The thread resumes in the ready state after 500 ms, NOT the running state.
The exact time that the thread enters the running state is dependant upon
the scheduler and cannot be determined by the developer.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Matt Parker]

Calling sleep using a Thread reference is bad practice.

Effectively what you are saying is nothing to do with the Thread argument,
more that calling a static method on an instantiated class is bad practice.
I don't see why you can dogmatically state that, since in reality it makes
no difference to code execution. As a rule of thumb, I'd suggest that doing
whatever made the code more readable would be prefereable.

Matt

 

[Tony Morris]

Effectively what you are saying is nothing to do with the Thread argument,

more that calling a static method on an instantiated class is bad

practice.
Yes, as stated at the beginning of this thread.

I don't see why you can dogmatically state that, since in reality it makes
no difference to code execution.

Yes, it does make a difference, a significant difference in fact.
No dogmatism intended, only clarity.

As a rule of thumb, I'd suggest that doing
whatever made the code more readable would be prefereable.

As already mentioned, the language designers allowed this one to slip
through and it must stay in order to maintain reverse compability. There is
never a good reason to access a static member/method/class using a
non-static context.


--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[P.Hill]

Apparently this is NOT how I tell the VM that I
[want] to sleep. If is not how do I?

Wow, I ask a quick question, because I was lead down
the garden path by .wait() and had forgotten about
Thread.sleep( n ) and I generate a heated debate!

I'd suggest that doing whatever made the code more readable
would be prefereable.

I'd say that consistency rules the day. sleep( n ) is a static method,
so it should called statically. This is particularly true
given that some modern IDEs like Eclipse will kindly tell you
(with a little Yellow warning triangle over in the margin)
that you are doing something it has been programmed to flag as
mis-leading -- referencing to a static method via an instance.

I'm with the IDE on this one (even it is probably programmable
to change that), so I wrote:

Thread.sleep( sleep );

As to

In a real (read non-trivial) application I would synchronize
against a locking object/method until the state that was required
was able to .notify() the lock, rather than rely on the vaguaries
of timing.

Actually this was really in a little daemon whose job
was to wake up every hour or so and see if there was
more work to do. It kindly re-reads its own resource file
before doing work, plus before and after sleeping
so no I didn't really need to work with notify().
Maybe someday, but right now the agile (XP) idea of
"the simplist that works" is also ruling the day
and the daemon will be unstoppable without a kill
while it is sleeping.

But don't let me stop a good raging debate; have fun!

Also, thanks for the quick and correct response. I
read the whole thread.

 

[Oscar kind]

As already mentioned, the language designers allowed this one to slip
through and it must stay in order to maintain reverse compability. There is
never a good reason to access a static member/method/class using a
non-static context.

As I was new to threads about a year ago, I found the non-static variant
to be much easier to understand. The static variant could (for all I knew)
have meant "put the JVM to sleep". Since then I've certified myself and
know better, but I think one should never underestimate the cluelessness
of a newbie.

Of course, it would have been better to use something like this:

Thread.sleep(500); // Put the current thread to sleep for at least 500ms.


Oscar

 

[Gordon Beaton]

As I was new to threads about a year ago, I found the non-static
variant to be much easier to understand. The static variant could
(for all I knew) have meant "put the JVM to sleep".

By the same token, the non-static variant could easily be
misunderstood:

Thread otherThread = new Thread(r);
otherThread.start();

...

otherThread.sleep(10000);

Unfortunately it doesn't do what was (apparently) intended here.

/gordon

 

[Chris Smith]

As I was new to threads about a year ago, I found the non-static variant
to be much easier to understand. The static variant could (for all I knew)
have meant "put the JVM to sleep". Since then I've certified myself and
know better, but I think one should never underestimate the cluelessness
of a newbie.

Oscar,

If you have no idea what a method does, you go read the documentation.
It's when you *do* understand what the method basically does that
misleading code makes a difference. The mistake you mention would
require not knowing the basic purpose of the Thread class.

It's far easier to make the mistake Gordon pointed out in his response.
Even more importantly, when you make that mistake the VM doesn't give
you any warning, and depending on the application you're likely to not
even notice that something is wrong until a much later stage of the
game.

Of course, it would have been better to use something like this:

Thread.sleep(500); // Put the current thread to sleep for at least 500ms.

I actually object heartily to this one as well. Comments that simply
repeat what the code said are the bane of all maintenance programmers.
They are the *most* likely to get out of date as the code is updated,
and they don't even add anything when they *are* current. They then
make it harder to find important comments by clouding up the code with a
comment every other line that says what ypou'd better already know if
you're reading Java code.

When I read code that contains comments like this, I delete them.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Ricardo]

P.Hill wrote:
[snip]

Wow, I ask a quick question, because I was lead down
the garden path by .wait() and had forgotten about
Thread.sleep( n ) and I generate a heated debate!
[snip]

But don't let me stop a good raging debate; have fun!

OK Paul, only because you took responsibility for starting this, this
load of fuel is attached to your response:

Using Thread.sleep(interval), the programmer demonstrates that he/she is

1. Unaware that the Thread static methods are ambiguous.
2. Arrogant enough that although the methods are ambiguous, yet chose to
demonstrate to his/her colleagues how to correctly call static methods.
3. Quite insensitive to the readability and clarity of the code/logic.
4. All of the above.

On the other hand..

Using Thread.currentThread().sleep(interval), the programmer
demonstrates that he/she

1. Is very aware and alert to the fact that the Thread static methods
are ambiguous.
2. Knows how to call static methods correctly (Thread.currentThread()).
3. Is sensitive to the clarity and readability of the code/logic.
4. All of the above.


They say that this is a very stressful job..
So, let us all have fun!