Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35857

Re: Interrupt code while running (from Form)

Show all headers | View raw

On 20/10/16 18:17, Eric Douglas wrote:
> On Thursday, October 20, 2016 at 12:49:59 PM UTC-4, Nigel Wade wrote:
>>
>> Thread management is the bit you've got wrong if you need to resort to jvisualvm to see why your program didn't finish.
>> You've failed to manage the lifecycle of your threads, and some are still running, preventing the JVM from exiting cleanly.
>>
>
> jvisualvm is the last resort debugger tool when you don't know what you did wrong.  I posted an example of one using simple Thread methods that does exit cleanly.  I'm asking you to show how SwingWorker makes that better.

There are examples in the tutorial. I provided the link in my first post on this thread.

Quite simply, SwingWorker manages the thread life-cycle for you. It creates the thread when you execute() your SwingWorker, then takes care of running its doInBackground() method. It executes a thread-safe method to process intermediate results and, on termination, has a thread-safe method to return a final result. When your program exits it doesn't block if the thread has not completed.


>
>>> As far as I know the SwingWorker should only be necessary if you are running something in a daemon thread that is going to need access to GUI.
>>>
>>
>> It's [almost] necessary when doing that, but there's no reason you can't use it for any other background tasks in a Swing GUI application.
>> The lifecycle methods in SwingWorker integrate very well with an event driven GUI. Otherwise you have to do everything manually, and if you get it wrong you end up messing with jvisualvm, or TaskManger or Ctrl-C to end your errant process/threads.
>
> There's no reason you can't use a car for every trip you take, even if you're only going next door.

Huh?

> Yes the SwingWorker can start literally every thread, many times it's just unnecessary.

Unnecessary? In Swing applications it's easier, cleaner, and works. Sure you can roll your own threads if you want to. You can roll your own code for doing pretty much anything for which convenience classes exist. It doesn't mean you should, or that you have to.

> You can kick off a background thread using a Runnable, and it can kick off a GUI task using SwingUtilities.invokeLater (or EventQueue.invokeLater) but it is just easier to use the SwingWorker when you know you might need both background and GUI, and it's particularly helpful when they're simultaneous (ie updating progress bar).
>

But SwingWorker does it all for you, and doesn't hang your process when the EDT finishes. What reason is there not to use it?

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Interrupt code while running (from Form) jkl <euclidalgorithm@gmail.com> - 2016-10-20 01:44 -0700
  Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-20 10:33 +0100
  Re: Interrupt code while running (from Form) Eric Douglas <e.d.programmer@gmail.com> - 2016-10-20 05:27 -0700
    Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-20 16:01 +0100
      Re: Interrupt code while running (from Form) Eric Douglas <e.d.programmer@gmail.com> - 2016-10-20 08:47 -0700
        Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-20 17:49 +0100
          Re: Interrupt code while running (from Form) Eric Douglas <e.d.programmer@gmail.com> - 2016-10-20 10:17 -0700
            Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-21 15:38 +0100
              Re: Interrupt code while running (from Form) Nigel Wade <nmw@local.domain> - 2016-10-21 16:38 +0100
        Re: Interrupt code while running (from Form) lewbloch@gmail.com - 2016-10-22 16:18 -0700

csiph-web