Skip to main content

Interview: André van Kouwen and the GMVC Project

October 17, 2009


I recently interviewed André van Kouwen, founder of a new project, GMVC (see also the Swing's Generic MVC interface page). André talked about why he started the project, the project's long-term objectives, and more. Here's a transcription of our interview.

Editor: Would you like to give us some brief background on yourself?

André: I am a Java programmer for the last 10 years and programmed before that in C++ and in C on 680x0. So, I am not a newbee. I have seen a lot of aspects of the software industry. I worked for many years as a software consultant in The Netherlands, United Kingdom and also almost 5 years in Canada.

Editor: When did you start the GMVC project?

André: I started it a couple of weeks ago by entering the first couple of files. But the idea has been in the making for at least two years. I tried a couple of items that worked out fine, and then the idea started to evolve further and further. I just came across, which seems the perfect place to share my ideas on the GMVC project, and even find people for bouncing off ideas, or even developers who would like to participate. Finding this site got me all excited to really start implementing this idea.

Editor: What problem are you trying to solve through the GMVC project?

André: I'm trying to solve is the problem of incorporating behaviour logic into often a generated fat client Swing-based GUI. Each View component has its specific interface to deal with, and I would like to have just one interface via only models, so that the Controller has no knowledge of the view used -- which is one of the most important aspects of project. I would like to have a Data model that sends out the object instances that have been changed, inserted or deleted; similarly, for components that can be selected, the model will be able to send out messages telling which object(s) instances are selected or deselected, and there will be an interface so that a controller can select or deselect certain objects instances in a view and an option to disable or enable any selection in the view. To give you an better idea: from a Controller a Table or Tree might behave exactly the same as a group of radio/checkboxes: it should make no difference to the Controller who is sending the message. The same would apply theoretically in that a Tree with a single leaf, or a table with a single row, behave the same as a push button (again from a Controller perspective). All view components mentioned, like button, radio and checkbox, tree and table, can be enabled/disabled for further selection(s). Selecting certain check/radio boxes in a group is also applicable, but selecting a push button should I think be impossible and throw an exception.

Editor: Can you show us some code snippets that demonstrate the essence of GMVC?

André: André : Sure, let us start with the 2 most important messages till now, first the DataModelChangeEvent:

public interface DataModelChangedEvent<B> {
    Set<B> getAdded();
    Set<B> getDeleted();
    Set<B> getUpdated();

The Generic B argument defines the actual Business object.

The selection change message is:

public interface SelectionChangedEvent<E> {
    Set<E> getSelected();
    Set<E> getDeselected();

In general a Controller listens for, i.e., Data Model changes by implementing
the following interface:

public interface DataModelChangedListener<B> {
    void accept(DataModelChangedEvent<B> modelChanged);

or a Controller listens for, i.e., Selection changes by implementing
the following interface:

public interface SelectionChangedListener<E> {
    void accept(SelectionChangedEvent<E> selectionChanged);

These Controller listeners can be registered at a SelectionModel Observable
of a JComponent:


and Controllers that are interested in selection changes:


The trick is now to normalize every Viewable and selectable JComponent to
comply to these interfaces if applicable.

This is just one aspect. Some Controller can also send DataModel change and
SelectionChange events back to these models. Controllers might also associate
an object instance(s) to a any kind of button so that that designated Set of
business object(s) is emited as a new Selection when the button is clicked.

Editor: Why do you consider it so important to address these issues?

André: The interfaces to deal with are complex even for more experienced Java programmers, because Swing has a vast number of public methods to choose from, and you get sort of lost in a lot of complex code. I want to make it very clear what needs to be done or what you need to do in order to control a View and Model combination properly.
In J2EE you have a clear business layer and an ORM layer; why not have a similar solution for Swing GUIs, so that there is a general approach in terms of implementation?

Editor: Can you tell me a bit more about the solution you're working on?

André: I want to add to each View/Model combination:

  1. Generic Observable listener for model changes that is a mediator between the Controller and the view/Model specific Model
  2. Generic Obserable listener for selection changes that is a mediator between the specific View's way of selecting object(s) and the Controller
  3. add an interface to the view/Model to enable/disable the view and to select or deselect specific Object instances
  4. have metadata annotations to descibe the business object that can be used by various views.

This metadata will, i.e., have a renderer for a single line view like JList, JCombobox, JTree, etc., but also describes the possible column indexes+renderers+column indexes when the business object is shown in a JTable, including the column name, resource name, etc. This is done using annotations and Reflection. Having the Generic interfaces means that you can change the type of View without having to change the controller interface definition and/or implementation.

Editor: How much progress have you made thus far?

André: Right now there is a very rough version that compiles and should give an experienced Swing programmer a good idea how the selection messages are composed for a number of components like a list and combobox, and also checkbox and push button. But all the code is still in a very rough state.

Editor: Do you have a planned sequence of development in mind? Is there a GMVC project roadmap?

André: Yes.

  • phase 1) is to implement the selection obserable interfaces for a JList/JTree, check/radio button and a push button
  • phase 2) is to implement the data model change obserable interface for a JList/JTree, check/radio button and a push button
  • phase 3) is to implement the selection by Controller interfaces for a JList/JTree, check/radio button and a push button
  • phase 4) model, selection and selection by Controller for JTable
  • phase 5) hope that other developers participate and implement these 3 interfaces for all other components

The GMVC ticket system will be used to coordinate these efforts.

Editor: Are others working on the project with you? If not, are you seeking help? If so, what kind of help do you seek? (help with design? development? testing? documentation?, etc.)

André: Right now the team consist out of two people but I hope many more that understand the strength of this solution will start to participate to implement the required functionality for the other components and use the library in their solutions. And yes: I really look for people that have a good understanding of Swing, Generics and Annotations and Reflection. I am also looking for developers that know how to develop, for example, Eclipse plugins.

Editor: What resources can people review to find out more about the background behind the GMVC and the project's objectives?

André: Right now it is the gmvc project page that is the billboard from which you have access to the available code and there will be also links to articles published on renowned sites like Javaworld and JavaLobby (the articles still need to be written). There are going to be Tutorials written to give the user a good idea of the framework/solution.

Editor: Thinking about Swing: what effect will GMVC have on current Swing users?

André: I hope they see the strength of this solution and will gradually move towards GMVC. GMVC is and will remain backwards compatable with Swing.

Editor: Is there anything users might consider "missing" when they apply the GMVC solution (once it's complete)?

André: Yes, you will miss a few very specific features like cell editing in a JTable, which is: a) very rarely used; and b) can be solved by having a table row editing detail Panel with OK and Cancel
buttons. There might be a few other features missing but so as far as I can predict it will be just a few that can still be solved using the standard Swing component

Editor: Does the GMVC project have any sample code that people interested in the project can review?

André: Yes. I've added a samples directory in Subversion. The car subdirectory includes sample code and a README that describes the test application.

Editor: What about support within IDEs?

André: Yes, I hope that is going to be possible to use annotations to identify what a View, model and Controller is. It would be nice to see which View/Model combinations are used in the application and that the developer can drag and drop these view/Model combinations so that there will be code generated that will take care of i.e. registring the Controller @ the observable view.

Editor: What are the most recent developments for the project?

André: There is currently a discussion with members of the GOF (Gang of Four) about the approach of this project: separation of the Controller from the View will support the basic principles of a good OO approach much better: "loose coupling" and "tight cohesion" could be great benefits of having logic in a Controller that is totally view independent. This would mean instead of a clasical MVC triangle design pattern, you would get a:

View <=> Model <=> Controller

or "VMC" design pattern.

Editor: Is there anything else that you want to mention?

André: I really really hope this approach will help to improve Swing's status as being a good platform for building Java based FAT clients, the industry complained that Swing was way to difficult, steep learning curve, etc., etc. I hope this will improve its reputation. Secondly I hope that this new approach will enable much less experienced developers to work on Swing GUIs, by lowering the complexity so that you don't need a Master's degree in order to develop a proper Java Swing GUI. Let's be honest, Swing is a real masterpiece, but for most Java programmers it's way too complex. I hope this GMVC will fill in gap. It is too bad that Java is used for a lot of very complex J2EE solutions, but there is no easy way of developing Java based GUIs.

Editor: Thanks for taking the time to let us know about your work and the GMVC project. I'll be following your progress.

width="1" height="1" border="0" alt=" " />
Related Topics >> GUI   |   Programming   |   Swing   |   Featured Article   |