• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 246
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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()}?
 
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
reply
    Bookmark Topic Watch Topic
  • New Topic