Proposal: Container-managed Swing?

Discussions

News: Proposal: Container-managed Swing?

  1. Proposal: Container-managed Swing? (25 messages)

    Thinking about ways to make concurrency in Swing easier, Ben Galbraith proposes Container-managed Swing, "a framework where screens and event handlers are managed by a "container" that automatically handles threads." The idea was partially inspired by Anders Heljsberg who thinks that Servlet/JSP/ASP model of having the container do the thread heavy lifting might be the future of a C# concurrency model.

    According to Ben, developers wishing to create high-performance Swing GUIs will need to use an asynchronous multi-threaded architecture. However, working with asynchronous multi-threaded code positions developers against "some of the toughest problems in modern software development".

    Like the Servlet and EJB specs, Ben proposes that we shouldn't be thinking about threads at all. How?
    Container-managed Swing. That is, a framework where screens and event handlers are managed by a "container" that automatically handles threads. Asynchronous screen population in the background, expensive user operations spawned by event listeners -- all managed by a container that does the heavy-lifting (including disabling the interface and displaying progress, where appropriate).[3] Just as a Servlet developer doesn't concern herself with managing a pool of worker threads to handle incoming HTTP requests, a Swing developer shouldn't need to worry about managing threads.
    According to Ben, no such framework exists today. What does the community think of this idea?

    Threaded Messages (25)

  2. This is an interesting idea, but there are some problems. Problem number one is Swing. Swing just does not work well for desktop apps. You could argue that the framework is too buly and complex or that the implementations are just too slow (I'm not going to argue why Swing is problematic), but there are so many better technologies for desktop apps out there. With Swing you either get an extremely poor user experience, or you get a decent one at the expense of far too much development effort. If we want to push GUI Java, I think effort is better spent improving SWT.

    That said, AJAX style web apps are going to put pressure on the desktop space in the coming years. Whether it's AJAX frameworks or XAML or something else, web deliverable thin apps offer perhaps a better approach for many applications.

    So I dunno, container managed Swing sounds plausible, but first you have to fix or replace Swing.
  3. This is an interesting idea, but there are some problems. Problem number one is Swing. Swing just does not work well for desktop apps. You could argue that the framework is too buly and complex or that the implementations are just too slow (I'm not going to argue why Swing is problematic), but there are so many better technologies for desktop apps out there. With Swing you either get an extremely poor user experience, or you get a decent one at the expense of far too much development effort. If we want to push GUI Java, I think effort is better spent improving SWT.That said, AJAX style web apps are going to put pressure on the desktop space in the coming years. Whether it's AJAX frameworks or XAML or something else, web deliverable thin apps offer perhaps a better approach for many applications.So I dunno, container managed Swing sounds plausible, but first you have to fix or replace Swing.

    I worked in a large-scale Swing project (more than 30K hours). We developed a framework for Swing and a container system (á lá EJB container) for Swing. Based on my experience, I disagree with you:

    1. Yes, there is a need to have a good framework for Swing based applications. Among others, the framework should simplify and standardize MVC.
    2. Yes, there is a need to kind-of-container system for Swing. Multi-threading and asynchronous communication are only some aspects. A "container" should provide primary-services like internationalization, security, validation, client-server communication management, logging, communication (messages and not simple events) etc.
    3. No, performance and user-experience is not as bad as you give the impression of. Of course, a Swing application is not supposed to be as responsive as a native application. But my experience from a large enterprise application shows that the application was quite responsive.

    All in all, in my experience, the problem is not necessarily Swing itself. It is rather the lack of a good framework for large-scale enterprise GUI development.
  4. Problem number one is Swing. Swing just does not work well for desktop apps. You could argue that the framework is too buly and complex or that the implementations are just too slow (I'm not going to argue why Swing is problematic), but there are so many better technologies for desktop apps out there. With Swing you either get an extremely poor user experience, or you get a decent one at the expense of far too much development effort. If we want to push GUI Java, I think effort is better spent improving SWT.That said, AJAX style web apps are going to put pressure on the desktop space in the coming years. Whether it's AJAX frameworks or XAML or something else, web deliverable thin apps offer perhaps a better approach for many applications.So I dunno, container managed Swing sounds plausible, but first you have to fix or replace Swing.

    FUD

    At least we all now know that you know shit about swing.
  5. Problem number one is Swing. Swing just does not work well for desktop apps. You could argue that the framework is too buly and complex or that the implementations are just too slow (I'm not going to argue why Swing is problematic), but there are so many better technologies for desktop apps out there. With Swing you either get an extremely poor user experience, or you get a decent one at the expense of far too much development effort. If we want to push GUI Java, I think effort is better spent improving SWT.That said, AJAX style web apps are going to put pressure on the desktop space in the coming years. Whether it's AJAX frameworks or XAML or something else, web deliverable thin apps offer perhaps a better approach for many applications.So I dunno, container managed Swing sounds plausible, but first you have to fix or replace Swing.
    FUDAt least we all now know that you know shit about swing.

    On the contrary, I believe you have exposed your ignorance of the subject with that rude reply.

    You may think Swing is great but put ANY desktop user in front of two applications one in SWT and one in Swing and I
    will bet $50 that 9 out of 10 will choose the SWT app.

    Regards

    Bryan
  6. Adding fuel to the flames[ Go to top ]

    The JavaServer Faces model kept me thinking recently and I am wondering if this wouldn't be a model to leverage as a standard architecture for Swing. So let me throw this in.

    Before rejecting this idea, take you time and think about it. I know that the Swing development model is different from the web application model, but force yourself not to think in problems but in options and assume that this can be resolved. Why building a new Swing framework when there is something on the table already?

    Frank
  7. On the contrary, I believe you have exposed your ignorance of the subject with that rude reply. You may think Swing is great but put ANY desktop user in front of two applications one in SWT and one in Swing and I will bet $50 that 9 out of 10 will choose the SWT app.Regards Bryan

    You could be right about the tone, to me both the words and
    their ordering hit some nerve, look at it as my "exec
    summary".

    Michael Connor put it better:
    The problem is that most Swing applications are not developed properly.
    The state of Swing reminds me of the chaos that ensued when novice developers were left to their own devices with JSP and went hog wild.

    I bet €500 that a) you cannot win a design award with SWT or
    b) realize _any_ app with SWT

    btt:
    What makes (Container-like!?) Swing design "hard" is
    event handling - it would be much easier with a single
    Windows like handle() [or whatever the name was] loop/hook
    for all GUI(model?) events - possibly breaking MVC and
    "bean" conformance.

    I don't understand anyones problem with Threads as
    invokeLater() is available and sufficient in most cases.
    Granted, getting JFreeChart to display/scroll 5k datapoints/
    sec realtime while other widgets remain responsive did
    require some tweaking.

    AFAIU article tries to "sell" yet another new layer on top
    of swing, making things easier for VB type of guys
    (but requiring new breed of Swing-Container-Framework
    "consultants"?) combined with some new Thread magic
    (need more information, apriori "animation" and "stopping"
    does not convince me of universal applicability).


    Regards
    Ricky
  8. I bet €500 that a) you cannot win a design award with SWT or b) realize _any_ app with SWT RegardsRicky

    And I would reply that I couldn't care less about wining
    any design awards. I want to build desktop applications
    that look and behave like all the other desktop applications
    on a users system and behave according to the global preferences that the user has set like any other application.

    I don't want the user to know or notice that it is a java
    application either. Usually you can tell because the fonts
    look funny or it redraws strangely or the usual key shortcuts don't work or it runs really slow or it is purple when all the users other applications have light gray frames.

    Guess what ... I DONT want my desktop applications to look or behave differently ...

    --b

    --b
  9. Saying that Java or Swing is too slow is like saying a car is too small: define the circumstances.

    People have been too slow in recognizing that Java and Swing certainly are fast enough for many, many applications, but also that both have increased in speed over the years. We still have slower startup, but execution speeds are quite good. In fact, there is seldom any meaningful difference in the performance of C, C++ and Java GUIs and applications.
  10. I have started working on a client container project. Its goal is to simplify swing developement, by leveraging an Inversion of Control (IoC) container, Picocontainer, and Java 5.0 annotations, and the JGoodies libraries.

    Version 0.1 has been released, and there is a little demo where you can test it and see how it works. Please help me on this project by providing feedback and ideas.
    http://sourceforge.net/projects/clico

    Ludovic
    ---

    Sample code:

    @VisualFeedback({VisualClue.MANDATORY_BACKGROUND})
    @Localisation(resource="customer_view")
    public class CustomerView extends JPanel {
        
        @Required
        @StringValidation(lengthMoreThan=2, lengthLessThan=8, format="
    w*")
        private JTextField name = new JTextField();
        @Required
        private JTextField company = new JTextField();
        @TypeValidation("email")
        private JFormattedTextField email = new JFormattedTextField();
        @TypeValidation("phone")
        private JFormattedTextField phone = new JFormattedTextField();

        private JLabel nameResult = new JLabel();
        private JLabel companyResult = new JLabel();
        private JLabel emailResult = new JLabel();
        private JLabel phoneResult = new JLabel();

        private JButton save = new JButton();
        
        @Init
        public void initActions(CloseAction closeAction) {
            save.setAction(closeAction);
        }
        
        @Init
    public void initBindings(BeanBinder bb) {
    bb.bind(name, Customer.PROPERTYNAME_NAME);
    bb.bind(nameResult, Customer.PROPERTYNAME_NAME);
    bb.bind(company, Customer.PROPERTYNAME_COMPANY);
    bb.bind(companyResult, Customer.PROPERTYNAME_COMPANY);
    bb.bind(email, Customer.PROPERTYNAME_EMAIL);
    bb.bind(emailResult, Customer.PROPERTYNAME_EMAIL);
    bb.bind(phone, Customer.PROPERTYNAME_PHONE);
    bb.bind(phoneResult, Customer.PROPERTYNAME_PHONE);
    }

        @Init
        public void initLayout(EasyFormLayout layout) {
            layout.setColumns("right:max(50dlu;pref), 3dlu, 50dlu, 3dlu, 50dlu, 3dlu");
            layout.setDefaultDialogBorder();
            layout.printlnSeparator("Customer details");
            layout.println("", name, nameResult);
            layout.println("", company, companyResult);
            layout.println("", email, emailResult);
            layout.println("", phone, phoneResult);
        }

    }

    public class Customer extends Model {
        public static final String PROPERTYNAME_ADDRESS = "address";
        public static final String PROPERTYNAME_NAME = "name";
        public static final String PROPERTYNAME_COMPANY = "company";
        public static final String PROPERTYNAME_PHONE = "phone";
        public static final String PROPERTYNAME_EMAIL = "email";

        private String name;
        private String company;
        private String phone;
        private String email;

        public Address getAddress() {
            return address;
        }

        public void setAddress(Address address) {
            Address oldAddress = this.address;
            this.address = address;
            firePropertyChange(PROPERTYNAME_ADDRESS, oldAddress, address);
        }

        public String getCompany() {
            return company;
        }

        public void setCompany(String company) {
    String oldCompany = this.company;
            this.company = company;
    firePropertyChange(PROPERTYNAME_COMPANY, oldCompany, company);
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
    String oldName = this.name;
            this.name = name;
    firePropertyChange(PROPERTYNAME_NAME, oldName, name);
        }

        public String getPhone() {
            return phone;
        }

        public void setPhone(String phone) {
    String oldPhone = phone;
            this.phone = phone;
    firePropertyChange(PROPERTYNAME_PHONE, oldPhone, phone);
        }

        public String getEmail() {
            return email;
        }

        public void setEmail(String email) {
    String oldEmail = this.email;
            this.email = email;
    firePropertyChange(PROPERTYNAME_EMAIL, oldEmail, email);
        }
    }
  11. Thinking about ways to make concurrency in Swing easier, Ben Galbraith proposes Container-managed Swing, "a framework where screens and event handlers are managed by a "container" that automatically handles threads." The idea was partially inspired by Anders Heljsberg who thinks that Servlet/JSP/ASP model of having the container do the thread heavy lifting might be the future of a C# concurrency model.According to Ben, developers wishing to create high-performance Swing GUIs will need to use an asynchronous multi-threaded architecture. However, working with asynchronous multi-threaded code positions developers against "some of the toughest problems in modern software development". Like the Servlet and EJB specs, Ben proposes that we shouldn't be thinking about threads at all. How?
    Container-managed Swing. That is, a framework where screens and event handlers are managed by a "container" that automatically handles threads. Asynchronous screen population in the background, expensive user operations spawned by event listeners -- all managed by a container that does the heavy-lifting (including disabling the interface and displaying progress, where appropriate).[3] Just as a Servlet developer doesn't concern herself with managing a pool of worker threads to handle incoming HTTP requests, a Swing developer shouldn't need to worry about managing threads.
    According to Ben, no such framework exists today. What does the community think of this idea?

    In my humble opinion, the GUI frameworks are too much focusing on event-mechanism, e.g. mouseClickedEvent. In my experience, business-related large-scale applications rather need better (preferrably standard) messaging-mechanism. On abstract level, a GUI application (including Swing) is not very much different from a server-side code, except for multi-user capability. On the server-side, frameworks and container systems have done a lot of good work with inter-component communication. However, I have not seen similar work on GUI-side. Am I totally wrong?
  12. In my experience, business-related large-scale applications rather need better (preferrably standard) messaging-mechanism.

    You mean like JMS?
  13. You mean like JMS?

    Not as heavy as JMS, but rather a light-weight messaging system within the GUI itself. As an implementation, one could use a simple JMS provider, but a Hub-Spoke would do it fine.

    The communication/messaging with server-side is another story. There are several scenarios: request/response, synchronous/asynchronous, threaded/not-threaded, queued/not-queued etc etc.
  14. We have done something similar (actually a colleague of mine) where we code the client much like we would code a struts application complete with embedded HSQL and a services layer (actually our server and client share a good chunk of code). I would agree with the general sentiment that there hasn't been much consolidation in this area outside of eclipse RCP. Personally, I have always been fond of the original ideas around InfoBus and how that was "supposed" to be extended beyond the client process to remote containers. Somnifugi (sp?) was interesting b/c it is an embedded jms api with a similar notion. It would be nice IMHO if enough of the eclipse RCP was detached from SWT to replace it with Swing (sound crazy? maybe ;-).
  15. Re: Like JMS[ Go to top ]

    In terms of a message bus system. You might want to check out

    SomnifugiJMS
    somnifugijms.dev.java.net
    SomnifugiJMS is an implementation of JMS that works inside a single JVM to send JMS Messages between Threads.

    or

    Werx2
    www.werx.org/werx2/werx2index.jsp
  16. Swing Demo App[ Go to top ]

    Swing is an incredible windowing invironment and applications run quite fast when they are developed properly. The problem is that most Swing applications are not developed properly.

    The state of Swing reminds me of the chaos that ensued when novice developers were left to their own devices with JSP and went hog wild. Before Struts, there were a lot of people that thought JSP was an unmaintainable nightmare. Struts taught the masses how to paint inside the lines when doing web development.

    While windowing is much more complex than the brain dead request/response mechanisms we use for the web, I do think it would be helpful for expert Swing developers to create an example application that demonstrates proper Swing techniques. The application could come with a library containing many common abstractions that could be reused. The following need to be addressed.

    - How to properly manage focus and hotkeys
    - How to handle undo/redo
    - How to create panels that can be used in JDialog, JFrame, and internal frames without rewrites.
    - How to properly used factories when creating controls
    - How to properly scope transactions and handle rollbacks
    - Basic validation, control population, and data harvesting

    All of these issues are addressed in a lot of different places but having a reference implementation that everyone could point to would be helpful.
  17. A Demo Swing App[ Go to top ]

    I've thought about writing such a demo Swing app. However, there is a thin line between such an app and writing a full blown framework. Eclispe on the SWT side provides many of the things you are looking for. The Jobs API essentially handles a good chuck of the threading issue. It has been a while since I looked at it but Netbeans Platform has a lot of what you mention as well for the Swing side of things. It isn't as documented and promoted as Eclipse however. Spring RCP is making progress building out a Swing based framework as well. It would be nice to see either Spring RCP take hold the way normal Spring has, Netbeans Platform cleaned up and documented, or a new solution such as the one Ben suggests with a few more features become popular. I've linked to a variety of pieces of the puzzle on my blog

    http://www.clientjava.com

    in the last year or so. It seems like every week there is a new commercial or open source framework popping up or a new plugin system. I wish things would consolidate into a few solid players like the web app framework area has.
  18. Eclipse Anyone?[ Go to top ]

    According to Ben, no such framework exists today. What does the community think of this idea?
    <br/>
    Doesn't exist??? How about Eclipse? It's a container managed (OSGi) GUI (SWT or Swing) framework for Java. But if you want to go and make another one, be my guest.
  19. First of all, I am sick and tired of people bashing swing for slow performance. It is fast, maybe not as fast as a native application, but fast enough. You can write very nice client applications using swing. For example Intellij Idea, Netbeans, DBVisualizer, Codeguide, etc are written using swing. From the UI point of view they are seem fast for me.

    Second, people say swing API is so vast and complex that regullar develpers have trouble usining it. When compared to web apps, yes there are more interfaces and classes in the swing API. This is simply because there are many more things that you can do in a swing application than in a web application. Having frameworks over the swing API it's a good thing. But that does not mean swing itself is bad. When you have web MVC frameworks (like Webwork, Spring, Struts, etc) over the servlets API, do you consider that servlet API is bad ?

    About the article: worth reading, but I do not like the tone . What I mean, is it implies that developers are just dumb people, that in fact do not know much about programming and should be isolated from such terrible things as threads, by using frameworks. I think frameworks should help you do your job easier, not allow you to be ignorant of basic things as threads.
  20. Proposal: Container-managed Swing?[ Go to top ]

    I think this is a great idea. I can't tell you how many times I've been developing a Swing-based app and thinking "If only this was more like EJBs".
  21. Proposal: Container-managed Swing?[ Go to top ]

    +1 Funny
  22. After developing or coaching a lot of Swing enterprise apps, I'm quite sure there is no "silver bullet" for the asynchronous native GUI programming problem: whenever you want to do something in the background, the application developer must decide what should happen until the background processing/server call is complete.

    Helpers like Spin are nice for a simple (read: limited) everything-gets-redrawn-but-is-blocked approach, but in many cases this is not enough, for example if the app has multiple windows that should act independent from each other.

    Using some libraries (shameless plug: see CUF for an example), it's getting easier to dispatch the async result back into the EDT and locally (on a per-frame base or a per-dialog base) block/unblock input events.

    But in the end, when you want async behavior, you must pay the price ;-)


    I strongly disagree with the notion that there are no threading problems in an ASP/Servlet context: au contraire, especially in a web app a lot of concurrent things can happen (multiple threads for the same user and session), which can never happen in a single-threaded-by-nature Swing app.
    For me, Swing development is way easier than web development, because Swing applications are statefull single-threaded (or developer controlled multi-threaded) whereas web applications are stateless multi-threaded by nature.

    I agree that a "container" or an "application framework" is usefull, but from my experience this framework should derive from a dialog concept, perhaps with some data binding (see JGoodies or CUF for a ValueModel implementation), state management and async dispatching support libraries.


    I also strongly disagree with the Swing bashing done in some comments: after developing GUI's both for Swing and .NET (.NET requires a lot low level Win32 work), i prefer Swing, as long as no Office/ActiveX integration is required.
    For an enterprise application the performance is _equal_, only the startup time of a .NET app is slightly faster.

    There is only one feature of C# that i'm desperately missing in Swing: delegates!

    Bye,

    Jürgen
  23. CUF[ Go to top ]

    CUF looks like XML programming. Isn't the compiler our friend?
  24. CUF[ Go to top ]

    The usage of XML in CUF is only "on top" of the rest of the stuff (data binding, states, ...).

    Depending on the situtation, either code or XML makes more sense, there is nothing in the XML description that can't be done in code.

    Usally, XML is more dense (less LOC); the XML builder implementation has a lot of checks + proper error messages, so any typo is usally detected at application start up time, not at run time.

    Bye,

    Jürgen
  25. Wrong Wrong Wrong[ Go to top ]

    The dreadest fallacy regarding concurency/threading is the belief that application developers can be offered concurency infrastructure without any effort on their part. This is plain wrong. We learned it in EJB model. People started to device hacks to bypass artificial limists set by containers wrt multithreading.

    To make a long story short, threading/concurrency are non-trivial subjects that require application developers be
    knowlegable (knowing what to do) and smart about the subject. As matter of fact no one SHOIULD BE ALLOWED TO WRITE ANY LINE OF MULTITHREADED CODE without reading and fully understanding Dog Lea's book. Otherwise you will have false of doing multithreading until it blows so badly.
  26. While we're on the subject of GUI's[ Go to top ]

    I'd just like to say that I'd be really happy to see AWT expanded to provide a much richer set of native controls available in Java right out of the box. I'm talking about things like Tabbed Dialogs, Toolbars, Wizards, and Tree Controls.

    Right now if I want to write a realistice app in Java that looks like a native app, my only choice is to use third party libraries.