• Post Reply Bookmark Topic Watch Topic
  • New Topic

Getting Rid of Deprecated Method suspend() Called in a Static Context  RSS feed

 
Kevin Simonson
Ranch Hand
Posts: 198
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've got a group of Java files that compile successfully, but that use deprecated methods {suspend()} and {resume()} for objects that extend {Thread}. I took a look at
"https://docs.oracle.com/javase/7/docs/api/" for class {Thread}, and noted that those two methods are indeed deprecated, and next to such declarations I saw, "For more
information, see Why are Thread.stop, Thread.suspend and Thread.resume Deprecated?" I clicked on that and that brought me to a web page with title
"Java Thread Primitive Deprecation" that had a section a little below its middle with title, "What should I use instead of Thread.suspend and Thread.resume?" That section
said that if I started with code:

I could get the desired effect with:

and then I go to the "run loop" for my {Thread} object and call {wait()} if {threadSuspended} is {true}. That looked pretty straightforward, so I
went into the code that was generating the messages about deprecated methods and started modifying them as the web page suggested. But at one
point {suspend()} was being called in a static method, like so:

Of necessity variable {threadSuspended} is a member of my class that extends {Thread}. How do I access it in static method {terminaExecucao()}?
 
Stevens Miller
Bartender
Posts: 1443
30
C++ Java Netbeans IDE Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kevin Simonson wrote:Of necessity variable {threadSuspended} is a member of my class that extends {Thread}. How do I access it in static method {terminaExecucao()}?

Static methods can access instances of objects, so your method could call a getter on your subclass of Thread and query the value of threadSuspended that way (likewise, a setter can alter threadSuspended for you). However, I strongly suspect this isn't going to solve your real problem, whatever it is. Typically, just following a rote approach to changing code isn't going to adapt real programs into the working, refactored versions you want them to be. Multi-threaded code is subtle stuff, where you really need to know what you're doing to be sure it's going to work.

You're doing the right thing by avoiding Thread.suspend and Thread.resume. Those are so dangerous that calling them "deprecated" seems somewhat too gentle, to me. Likewise, Object.notify and Object.wait, while still considered valid methods, are best left to legacy code, and not used directly anymore. Here's advice from a smarter head:

In Effective Java, 2d ed, Joshua Bloch wrote:In summary, using wait and notify directly is like programming in "concurrency assembly language," as compared to the higher-level language provided by java.util.concurrrent. There is seldom, if ever, a reason to use wait and notify in new code. (emphasis in original)


I do a lot of multi-threaded coding, and never need Object.wait nor Object.notify. I tend to use one of the implementations of the BlockingQueue interface, a Semaphore, and a few other members of java.util.concurrent. I'd suggest you look at those classes and see if maybe they can simplify what you're doing. Feel free to post back here if you need help.
 
Henry Wong
author
Sheriff
Posts: 22861
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kevin Simonson wrote: I clicked on that and that brought me to a web page with title "Java Thread Primitive Deprecation" that had a section a little below its middle with title, "What should I use instead of Thread.suspend and Thread.resume?" That section said that if I started with code...


Okay, but as Stevens mentioned, you are kinda doing it by rote... What is being suggested is not a cut and replace operation. With the suspend() and resume() method, a thread is able to control another thread. The suggested replacement simply sets a variable, and sends a notification. It doesn't actually do any suspending or resuming of any other thread.

Kevin Simonson wrote:
and then I go to the "run loop" for my {Thread} object and call {wait()} if {threadSuspended} is {true}. That looked pretty straightforward ...


And this is the part that is *not* straightforward. In fact, it is very far from straightforward. Remember, in the suspend() and resume() model, this thread did not know that it was being suspended/resumed. It can do whatever it wanted.

What if this thread doesn't have a "run loop"? And even if it did, what if this thread takes too long for each iteration (that it is not suspending in time)? What if it is doing I/O? etc. This code may require a complete "re-architecture" to make it cooperative, so that it can "suspend" and "resume" itself, when it is communicating with the thread requesting the suspend/resume.

Henry
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!