0

It's been some time since I worked with java, and it seems that since I last worked with it, stop and destroy have been deprecated on threads. This is annoying because it means that I can't create anonymous classes to do basic threaded work like so:

    final Integer finChannelId = channelId;
    Thread thread = new Thread() {
        public void run() {
            while (true) {
                System.out.println("I'm doing work on " + finChannelId);
            }
        }
    };
    thread.start();
    // Go off and do something else for a while.
    thread.stop();

Is this pattern simply no longer valid? Do I need to create an explicit class now for every tiny worker thread?

directedition
  • 11,145
  • 18
  • 58
  • 79
  • 5
    It was deprecated in Java 1.2 (December 1998). Guess it's been a while, huh? Note that there's nothing specific about using anonymous classes here - what works in an anonymous inner class would work in a named class and vice versa. – Jon Skeet Aug 08 '14 at 20:47
  • 4
    I can see no connection between using anonymous classes and `stop` being deprecated. Can anyone assist me in my poor understanding? Are you just referring to the fact that threads are less useful to you without `stop` so you won't be able to use threads? That has nothing to do with using an anonymous subclass of `Thread` (which is BTW, even if not deprecated, strongly discouraged). – William F. Jameson Aug 08 '14 at 20:48
  • The pattern is valid. Technically, using `Thread#stop` is not valid anymore, the method is deprecated and you should not use it. – Luiggi Mendoza Aug 08 '14 at 20:49
  • With an anonymous class, I can't call methods on it from the outside that aren't a part of the Thread class. – directedition Aug 08 '14 at 20:49
  • And yes, it has been quite a while. – directedition Aug 08 '14 at 20:50
  • If Thread.stop is not valid, how then do I stop a thread spawned from an anonymous class? – directedition Aug 08 '14 at 20:52
  • 1
    Exactly---so where's the connection between what you have just said and what you are complaining about? `stop` is a method of `Thread`, you can call it on the anonymous class. – William F. Jameson Aug 08 '14 at 20:52
  • William F. Jameson - Yes, I *can* call it on an anonymous class, but doing so is not in keeping with best practices, as the 'stop' call is deprecated. – directedition Aug 08 '14 at 20:52
  • 1
    You stop a thread by *asking it nicely*; technically speaking, that means calling `Thread#interrupt()` and making sure your thread implementation code actually cooperates with the cooperative interruption mechanism. – William F. Jameson Aug 08 '14 at 20:53
  • Ahh, Thread#interrupt(), that's what I'm missing! Thank you very much! – directedition Aug 08 '14 at 20:54
  • `doing so is not keeping with best practices`---`stop` is as deprecated when you dispatch it against the `Thread` subtype as when dispatching againts `Thread` itself. Exactly the same method is called in both cases. – William F. Jameson Aug 08 '14 at 20:54
  • for an example of calling interrupt on a thread see http://stackoverflow.com/q/5915156/217324 – Nathan Hughes Aug 08 '14 at 20:59

3 Answers3

4

It is no longer a valid way. Using scheduling methods such as stop have been deprecated because they could potentially leave work in an invalid state. See this article for more information.

If you are doing such anonymous work, I would recommend a ThreadPoolExecutor.

Otherwise, if you want to continue doing it the way you are doing right now, you should use Thread#interrupt(), or use a boolean value outside of the anonymous Thread and change that to stop execution.

0

Yes, stop and destroy have been deprecated for many reasons. The way that your creating your thread is ok, but you need to come up with a different way of stopping it. Use a boolean variable that you can set equal to 'true' or 'false' to stop.

See the following post Thread.stop() - deprecated

Community
  • 1
  • 1
tier1
  • 6,303
  • 6
  • 44
  • 75
0

Thread#stop has been deprecated for very strong reasons. Basically, it was broken from the start and your code using it was thus broken as well. The thread could be stopped in the middle of a critical section (covered with a lock), leaving work half-finished and permanently breaking the instance it was working on. After such an event there is absolutely no guarantee as to the integrity of the system state.

What was instead introduced to Java is the interruption mechanism: there's a flag you can check on Thread.currentThread() to see if someone called interrupt on it. If you see that flag on, you make sure the thread's implementation leaves what it was doing, cleans up and exit.

William F. Jameson
  • 1,833
  • 9
  • 14