The Artima Developer Community
Sponsored Link

Weblogs Forum
How Much Concurrency Should be Exposed in a UI Toolkit?

34 replies on 3 pages. Most recent reply: Jun 21, 2007 8:41 AM by Achilleas Margaritis

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 34 replies on 3 pages [ « | 1 2 3 | » ]
Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 15, 2007 8:15 AM
Reply to this message Reply
Advertisement
> Computations which take time should be executed in a
> different thread, so as that the UI remains responsive.
> Short computations should be executed in the same thread
> as the GUI.
>
> It's a simple rule really, and I don't know why is there a
> topic in Artima about this. What's more to say on this?

The rules for how to perform threading in a Swing application isn't the topic of this discussion.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 15, 2007 8:48 AM
Reply to this message Reply
> Computations which take time should be executed in a
> different thread, so as that the UI remains responsive.
> Short computations should be executed in the same thread
> as the GUI.
>
> It's a simple rule really, and I don't know why is there a
> topic in Artima about this. What's more to say on this?

Indeed, it's a simple rule, and it works well, in fact, for what it is.

The trouble, though, is that many other UI APIs don't have this sort of requirement. In Ajax, for instance, you simple register callbacks on, say, HttpURLRequest; Flex works the same way.

One answer to this may be that Swing and those other APIs are totally different, and that Swing is really more powerful and was designed for a different purpose. That may well be so.

My point merely was that there is a large class of applications where I'd want to use Swing much, much more than I'd use, say, an Ajax library. But when you look at the amount of code, and amount of work, needed to accomplish the same functionality in one vs the other, I'd say that Swing requires more of both. (Ajax has other problems, of course, which is exactly why I'd rather use Swing. Flex seems to require less code than Swing, and does solve some of the problems with Ajax.)

As someone mentioned, JavaFX may be the answer, and that's great news then.

Ronald Tetsuo Miura

Posts: 22
Nickname: ronaldtm
Registered: Jan, 2004

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 15, 2007 11:33 AM
Reply to this message Reply
> The trouble, though, is that many other UI APIs don't have
> this sort of requirement. In Ajax, for instance, you
> simple register callbacks on, say, HttpURLRequest; Flex
> works the same way.

If that is what you want, wouldn't be easy enough to create a SwingWorker utility class that only does a http request, and then runs a callback (in the EDT) you pass in the constructor? The syntax (usually an anonymous inner class) isn't that beautiful, but works well enough.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 18, 2007 8:49 AM
Reply to this message Reply
> > Computations which take time should be executed in a
> > different thread, so as that the UI remains responsive.
> > Short computations should be executed in the same
> thread
> > as the GUI.
> >
> > It's a simple rule really, and I don't know why is there
> a
> > topic in Artima about this. What's more to say on this?
>
> The rules for how to perform threading in a Swing
> application isn't the topic of this discussion.

I respectfully disagree. The original topic says:


(1) Do you agree that the correct use of Swing's threading model induces complex and unattractive application code?
(2) If so, what do you think should be done to make the Swing programming model easier?
(3) How much concurrency do you think should be exposed in a UI toolkit?


The answers are simple, really:

#1: nope.
#2: nothing.
#3: whatever is necessary.

So it ultimately boils down to "if the task at hand is a long computation, put it in a separate thread, otherwise don't".

Charlie Cocchiaro

Posts: 1
Nickname: ccocco
Registered: Jun, 2007

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 18, 2007 9:12 AM
Reply to this message Reply
Swing GUI's can be optimized fairly well for responsiveness when performing a long-running task, using a combination of SwingUtilites.invokeLater() and the SwingWorker thread.

One way to accomplish this is to create, display, and update an indeterminate JProgressBar (within a dialog) on the Event Dispatch Thread, using SwingUtilitities.invokeLater(). Assuming the JProgressBar is going to be continuously updated at a specific interval, the Event Dispatch Thread is free to allow repaints to be performed.

Once the progress dialog is displayed, the SwingWorker thread should be started, and the long-running task executed in the contruct() method. When the task completes, the progress dialog should be removed via the finished() method of the SwingWorker thread, which is actually called from the Event Dispatch Thread.

In cases where a task requires updating the GUI periodically while the long-running task executes, calls to SwingUtilitites.invokeLater() can be performed from the contruct() method of the SwingWorker thread to update the GUI on the Event Dispatch Thread.

For example, if a GUI were reading a directory of image files, creating a thumbnail image of each, and rendering them as each one was created, it could accomplish this via the construct() method by reading the image, creating the thumbnail image, adding the thumbnail image to the panel, and calling SwingUtilities.invokeLater() to force an update of the panel. Once there were no more images to process, the finished() method would be called so that the progress dialog could be removed. For each thumbnail that was processed, the filename of it could be updated in the progress dialog so that the user saw which file was being processed, along with a count to indicate how many images were left (i.e. file1.jpg - 2 of 20)...

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 18, 2007 10:04 AM
Reply to this message Reply
> > > Computations which take time should be executed in a
> > > different thread, so as that the UI remains
> responsive.
> > > Short computations should be executed in the same
> > thread
> > > as the GUI.
> > >
> > > It's a simple rule really, and I don't know why is
> there
> > a
> > > topic in Artima about this. What's more to say on
> this?
> >
> > The rules for how to perform threading in a Swing
> > application isn't the topic of this discussion.
>
> I respectfully disagree. The original topic says:
>
>
> (1) Do you agree that the correct use of Swing's threading
> model induces complex and unattractive application code?
> (2) If so, what do you think should be done to make the
> Swing programming model easier?
> (3) How much concurrency do you think should be exposed in
> a UI toolkit?
>

>
> The answers are simple, really:
>
> #1: nope.
> #2: nothing.
> #3: whatever is necessary.
>
> So it ultimately boils down to "if the task at hand is a
> long computation, put it in a separate thread, otherwise
> don't".

Note that none of your answers explains the rules for Swing threading because the questions don't ask for that. So your previous post was off-topic but your latest is on-topic.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 18, 2007 10:08 AM
Reply to this message Reply
> > The answers are simple, really:
> >
> > #1: nope.
> > #2: nothing.
> > #3: whatever is necessary.
> >
> > So it ultimately boils down to "if the task at hand is
> a
> > long computation, put it in a separate thread,
> otherwise
> > don't".
>
> Note that none of your answers explains the rules for
> Swing threading because the questions don't ask for that.
> So your previous post was off-topic but your latest is
> on-topic.

Actually, I take part of my last post back. Answering the questions was on-topic, but the last sentence is back to offering advice on doing Swing apps rather than discussing whether changes are needed.

Ronald Tetsuo Miura

Posts: 22
Nickname: ronaldtm
Registered: Jan, 2004

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 18, 2007 2:10 PM
Reply to this message Reply
What I don't get is, why Javascript's thread handling is superior, if it does not have threading support in the first place. It is a limitation, not a feature.

And, I still don't get what is the problem in using the main thread just to queue the creation the initialization code. Do just that and everything is fine, everything runs in the EDT, unless you create a thread yourself. It's simple. Not really enforceable but, poor programmers will always do bad things no matter what you do.

And if you do any heavy processing, you'll have to do it in a background thread, but you would anyway, even if using another toolkit (which probably will also have some kind of threading issue).

I think the new Swing App Framework will kinda 'fix' this. Instead of calling the EventQueue.invokeLater() explicitly, you have to implement a initialization callback, and the initial EventQueue invocation will be implicit. It does much more than that, of course.

But, even without it, it would not be difficult to create a base class to do it:

import java.awt.EventQueue;
 
public abstract class Application {
 
    public abstract void startup(String... args) throws Exception;
 
    public static void launch(final Class<? extends Application> appClass, final String... args) {
        try {
            EventQueue.invokeAndWait(new Runnable() {
                public void run() {
                    Application app;
                    try {
                        app = appClass.newInstance();
                        app.startup(args);
                    } catch (Exception e) {}
                }
            });
        } catch (Exception ex) {
            throw new RuntimeException(ex.getCause().getMessage(), ex.getCause());
        }
    }
}


And apps would not be required to use EventQueue directly, thus making it harder to write bad code:
public class SimpleApp extends Application {
 
    @Override
    public void startup(String... args) throws Exception {
        System.out.println(Thread.currentThread().getName()); //prints 'AWT-EventQueue-0'
    }
 
    public static void main(String[] args) {
        launch(SimpleApp.class, args);
    }
}



Then, what how much concurrency is exposed (not considering the concurrency you create yourself)?

Timo Stamm

Posts: 3
Nickname: tstamm
Registered: Jun, 2007

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 18, 2007 3:39 PM
Reply to this message Reply
> > We just need first class functions with a decent
> syntax: [...]
>
> Well, this simplifies the code, but doesn't solve the
> multithread problem.

What multithread problem?

Right know, the code bloat of writing a Swing app is just too much. The article recognizes this.


> > But what about JavaFX? [...]
>
> I think it tries to compete mainly with Flash, as a rich
> and dynamic 'applet' embedded in web pages

And we all know how well applets work out...

Seriously, the current JRE isn't going to compete with Flash in the browser simply because of the startup time.


> But, in 'enterprise' applications [...] I don't see it getting much traction.
> Well, unless it becomes REALLY easy to make good UIs with
> it (including forms, tables and other 'enterprisey' stuff).

Think about how a declarative language just for this job might look like. Then take a look at JavaFX again.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 19, 2007 4:40 AM
Reply to this message Reply
> > > The answers are simple, really:
> > >
> > > #1: nope.
> > > #2: nothing.
> > > #3: whatever is necessary.
> > >
> > > So it ultimately boils down to "if the task at hand
> is
> > a
> > > long computation, put it in a separate thread,
> > otherwise
> > > don't".
> >
> > Note that none of your answers explains the rules for
> > Swing threading because the questions don't ask for
> that.
> > So your previous post was off-topic but your latest is
> > on-topic.
>
> Actually, I take part of my last post back. Answering the
> questions was on-topic, but the last sentence is back to
> offering advice on doing Swing apps rather than discussing
> whether changes are needed.

It's obvious, really: no changes are needed in the Swing threading model.

I hope the above is not too difficult to digest :-).

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 19, 2007 7:26 AM
Reply to this message Reply
> It's obvious, really: no changes are needed in the Swing
> threading model.
>
> I hope the above is not too difficult to digest :-).

I think Sun made a poor design choice when they forced all Swing apps to be multithreaded by virtue of putting GUI events in a separate thread on startup. They could have started with everything in the same thread and then let the developer decide if there was a need to create worker threads.

Having said that, I don't think they could realistically change the behavior now and Sun is opposed to any fundamental changes in Java anyway.

Ronald Tetsuo Miura

Posts: 22
Nickname: ronaldtm
Registered: Jan, 2004

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 19, 2007 7:49 AM
Reply to this message Reply
> I think Sun made a poor design choice when they forced all
> Swing apps to be multithreaded by virtue of putting GUI
> events in a separate thread on startup. They could have
> started with everything in the same thread and then let
> the developer decide if there was a need to create worker
> threads.

You'd like Swing have used a SWT-like approach? If so, instead of just running the inialization code in the EDT, you'd have to code the event loop yourself. Isn't it just changing from one problem to another?

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 19, 2007 1:24 PM
Reply to this message Reply
> You'd like Swing have used a SWT-like approach? If so,
> instead of just running the inialization code in the EDT,
> you'd have to code the event loop yourself. Isn't it just
> changing from one problem to another?

I guess I don't get your point. Why would moving the functionality of the EDT into the initial thread require the application to code an event loop?

Ronald Tetsuo Miura

Posts: 22
Nickname: ronaldtm
Registered: Jan, 2004

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 19, 2007 2:55 PM
Reply to this message Reply
> I guess I don't get your point. Why would moving the
> functionality of the EDT into the initial thread require
> the application to code an event loop?

The EDT has a loop that handles the event queue. If it isn't running in a separate thread, you have to start a loop doing it.

The following code is a 'hello world' app using SWT:

import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Display;
public class Shell2 extends Shell1 {
   public static void main(String args[]) {
      try {
         Display display = Display.getDefault();
         Shell2 shell = new Shell2(display, SWT.SHELL_TRIM);
         shell.open();
         shell.layout();
         while (!shell.isDisposed()) {
            if (!display.readAndDispatch())
               display.sleep();
         }
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
   public Shell2(Display display, int style) {
      super(display, style);
      setText("SWT Application");
      setSize(500, 375);
      final Button button = new Button(this, SWT.NONE);
      button.setText("button");
      button.setBounds(147, 90, 107, 47);
      setCheckBoxText("My Label");
      getHelloButton().setText("World");
      getHelloButton().setLocation(10, 82);
   }
}


Well, if we were programming in Clipper or DBase, we'd have complete control of the program loop. But that was a long time ago. Today, with the event-based GUI toolkits, this has become inviable, because they mostly use the Inversion of Control pattern (you don't call them, they call you) through event handlers, and they must handle the program loop, directly or indirectly.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 19, 2007 3:36 PM
Reply to this message Reply
> > I guess I don't get your point. Why would moving the
> > functionality of the EDT into the initial thread
> require
> > the application to code an event loop?
>
> The EDT has a loop that handles the event queue. If it
> isn't running in a separate thread, you have to start a
> loop doing it.
>

Please explain why you think this loop can't be in the same thread as the application and still be performed by the framework/toolkit rather than the application itself.


> The following code is a 'hello world' app using SWT:
>

I wasn't suggesting using the SWT approach.

> Today, with the event-based GUI toolkits,
> this has become inviable, because they mostly use the
> Inversion of Control pattern (you don't call them, they
> call you) through event handlers, and they must handle the
> program loop, directly or indirectly.

Sure, callbacks have been around a very long time, but they aren't an important factor in determining whether multithreading is necessary.

Flat View: This topic has 34 replies on 3 pages [ « | 1  2  3 | » ]
Topic: How Much Concurrency Should be Exposed in a UI Toolkit? Previous Topic   Next Topic Topic: New Python 3000 Video and Slides

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use