this.wait( sleep );

[Andrew Thompson]

Ricardo wrote:
....

They say that this is a very stressful job..

What, programming, or helping people?

Computer programming, (less the users)
is one of the most calming things I do.

Dealing with people, OTOH, is probably
the single most irritating. The best way for
me to resist choking the point into the
client/user is to deal with them only in
written form!

So, let us all have fun!

Most certainly! It's always fun
coming up with new places to
hide the bodies. ;-)

 

[Collin VanDyck]

Computer programming, (less the users)

is one of the most calming things I do.

Likewise, unless one of two other conditions are met:

1. needing to learn a completely new set of concepts in record time to meet
a deadline.
2. being micromanaged.

I definitely do better being given a set of goals to reach by date X, and
reaching them.

Most certainly! It's always fun
coming up with new places to
hide the bodies. ;-)

Consider the staircases. Most professionals will only take the stairs if
the elevator is on fire.

 

[Chris Smith]

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.

Ricardo,

Why do you think static methods in Thread are ambiguous? The rest of
your post seems to depend on that rather shaky assumption.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Ricardo]

Ricardo,

Why do you think static methods in Thread are ambiguous? The rest of
your post seems to depend on that rather shaky assumption.

Other than the fact that it's very useful to make my argument? ... hmm...

First, that same Thread class has class methods that work with the
current ThreadGroup: activeCount() and enumerate(Thread[]). Both could
be accessible by getCurrentThread().getThreadGroup().activeCount() and
getCurrentThread().getThreadGroup().enumerate(Thread[]). Those short
cuts the API provided are not in place.

In addition, consider the naming convention used in this mix of class
and instance methods:

start() /* instance method */
sleep() /* static method, Current Thread */
stop() /* DEPREATED, instance method */
resume() /* DEPREATED, instance method */
interrupt() /* instance method */
interrupted() /* static method, Current Thread */
isInterrupted() /* instance method, Current Thread */

The result is a very obscure class.

I therefore joined the camp that chose to clarify the intention of the
code, and bite the overhead of Thread.currentThread() in order to
protect clarity. The intention is not to mislead the visiting
programmer, but to insure readability (at the expense of criticism and
awkward calls to static methods).

 

[Ricardo]

Ricardo wrote:
...



What, programming, or helping people?

Computer programming, (less the users)
is one of the most calming things I do.

Dealing with people, OTOH, is probably
the single most irritating. The best way for
me to resist choking the point into the
client/user is to deal with them only in
written form!

Usually, this is remedied when you receive the check from the client/user.

Stress is when you have to sign a paycheck for a programmer whose code
you've been trying to read for the past three days + nights.. That's
abuse ;-)

 

[Dale King]

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.

If you use Eclipse IDE then we can turn back time. It has an option to give
either a warning or error for this and several other constructs.

 

[xarax]

/snip/
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.

It may have something to do with real-time embedded
JVM implementations, which can offer such high
resolution timers.

 

[Tony Morris]

It may have something to do with real-time embedded

JVM implementations, which can offer such high
resolution timers.

When I said that the language designers overlooked it, I didn't mean it as
speculation.
I have discussed this topic personally on IRC with the language designers.

--
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]

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".

Hm, in my case - just a little daemon that was waiting to
check if it had anything to do, that would NOT have been
a bad assumption, since that IS what I wanted

Since then I've certified myself and
know better, but I think one should never underestimate the cluelessness
of a newbie.

Let's see, says the newbie,
(1) Thread.sleep( n ), no that doesn't sound right that seems to
universal, who knows maybe all threads get slept.
(2) Thread.currentThread(). ?

Wait one minute, all I see is static sleep( n )

Hm, let's look at the JavaDoc (which in a modern IDE shows up with
one keystroke right on the screen). Oh I see, the static one does put
the current thread to sleep; Okay, I'll use that. I'll have to try
remember that.

The problem is not that the newbie will think that static sleep
is the wrong API, because there is no other thing to choose from,
other than wait() which either (1) in the docs talks about waiting
for something else which ain't right, or (2) does NOT work
if you just try it.

I'm not sure what weird state you think the code can get into
by a newbie not getting it; what nearly working or sometimes failing
code will he write using a bad guess at the functionality of static
sleep( n )?

-Paul

p.s. What have I gotten myself into?

 

[P.Hill]

I actually object heartily to this one as well.

at worst the comment could be

Thread.sleep(500); // current thread

Repeating the verb sleep and the value 500 doesn't do anything.

-Paul

 

[Jon A. Cruz]

Jezuch wrote:




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

Actually, it is bogus, as it is misleading as to how you sleep threads.
sleep(long) *always* sleeps the current thread, regardless of which
thread it is called on.

 

[Jon Skeet]

I therefore joined the camp that chose to clarify the intention of the
code, and bite the overhead of Thread.currentThread() in order to
protect clarity. The intention is not to mislead the visiting
programmer, but to insure readability (at the expense of criticism and
awkward calls to static methods).

You think that making static methods look like they're actually
instance methods *increases* readability? That's a new one to me...

If someone didn't know what thread Thread.sleep(...) would affect, they
could easily look it up. They're unlikely to actually get the wrong
impression from it. However, if they see
Thread.currentThread().sleep(...) they could *very* easily get the
wrong impression. That, to me, is lowering readability.

 

[xarax]

You think that making static methods look like they're actually
instance methods *increases* readability? That's a new one to me...

If someone didn't know what thread Thread.sleep(...) would affect, they
could easily look it up. They're unlikely to actually get the wrong
impression from it. However, if they see
Thread.currentThread().sleep(...) they could *very* easily get the
wrong impression. That, to me, is lowering readability.

I certainly hope there is a Java "lint" tool that will
complain loudly about calling a static method via an instance.

 

[Michael Borgwardt]

I certainly hope there is a Java "lint" tool that will
complain loudly about calling a static method via an instance.

As Paul Hill noted, Eclipse can be configured to (and does per default)
give warnings when that is done.

 

[Collin VanDyck]

I certainly hope there is a Java "lint" tool that will

complain loudly about calling a static method via an instance.

I know that Eclipse complains about it. You can set that as an option in
the preferences, so I'd imagine you could turn that warning on with an
option to the compiler.

 

[Ricardo]

You think that making static methods look like they're actually
instance methods *increases* readability? That's a new one to me...

Absolutely not..

The only exceptions: Thread.sleep(..), Thread.yield(),
Thread.holdsLock(..) and Thread.dumpStack().

If those methods were named more properly (i.e., yieldCurrentThread()),
or made part of a CurrentThread helper class, you'd be proud of how I
make those calls.

If someone didn't know what thread Thread.sleep(...) would affect, they
could easily look it up. They're unlikely to actually get the wrong
impression from it. However, if they see
Thread.currentThread().sleep(...) they could *very* easily get the
wrong impression. That, to me, is lowering readability.

I'm convinced that Thread.currentThread().sleep(..) would give the exact
impression as to which thread is being affected. I know this is not
what you're saying, but it's exactly what's intended by this funny code.

I'm sure that neither you nor Chris would design a class with an
interface similar to that of Thread. If you were to commit such an act,
and if I were the user of that class, I'd be committing that same sin again!

 

[Dale King]

at worst the comment could be

Thread.sleep(500); // current thread

Repeating the verb sleep and the value 500 doesn't do anything.

But often to clarify I will do something like:

Thread.sleep( 500 /* milliseconds */ );

 

[Jezuch]

U¿ytkownik Ricardo napisa³:

I'm convinced that Thread.currentThread().sleep(..) would give the exact
impression as to which thread is being affected. I know this is not
what you're saying, but it's exactly what's intended by this funny code.

No offence, but my first impression after seeing this is that the author of
such code is really clueless... It's so newbie-ish.
One of my .sigs says "Don't mistake lack of talent for genius"

 

[Ricardo]

U¿ytkownik Ricardo napisa³:



No offence, but my first impression after seeing this is that the author
of such code is really clueless... It's so newbie-ish.
One of my .sigs says "Don't mistake lack of talent for genius"

Not to worry..

As you grow up and mature some more, you'll come to appreciate and
comprehend the experiences and wisdom of those great ones before you.

Consider replacing your SIGs with:
The worst of all deceptions is self-deception -- Plato

 

[Jon A. Cruz]

I'm convinced that Thread.currentThread().sleep(..) would give the exact
impression as to which thread is being affected. I know this is not
what you're saying, but it's exactly what's intended by this funny code.

And I've very convinced that exactly that kind of code opens things up
to more maintenance errors.

Go lookup IBM's article on the 'rouge tile' bug pattern for an example
of the kind of thing I'm talking about.