Post-DM Thoughts
Posted by Eitan Suez Wed, 21 Mar 2007 20:52:00 GMT
It's been over a week since the Desktop Matters conference where I presented on JMatter. Although I did blog about general impressions of the conference on my java.net weblog, I'm not sure why I haven't really started collecting my thoughts of the conference as they apply to JMatter.
So here is a first post. Hopefully this will not be the last on this topic.
The Desktop Matters conference lasted approximately 1.5 days. It started on a Thursday afternoon and ended late on Friday. Throughout this time, we listened to various speakers talk about some aspect of Desktop development.
One particular session, given by Ben Galbraith, made some interesting points:
- It tried to summarize current pain points with Java Swing
- It tried to express visually the need for a framework for building applications with Swing
This was the list of pain points:
- GUI Creation and Maintenance
- Concurrency
- Binding and Validation
- Various API Problems
What I find interesting is trying to gauge JMatter against each of these points. Does JMatter help mitigate these problems?
JMatter completely does away with the first: "GUI Creation and Maintenance." With JMatter it's not even a question of how easy is it to create and maintain your GUI. GUI Creation and maintenance disappears.
The second pain point speaks to the fact that developers have to be very careful to perform UI-related operations on the event dispatch thread, and conversely to ensure that non-ui operations (particularly long-running ones) are performed off that thread. Again, in this respect, JMatter completely removes this burden from the plate of the application developer. Methods are exposed as actions using a simple convention. The framework ensures that the action is invoked off the edt and that the view for the object that the method returns is constructed back on the edt.
The third point is likewise addressed by the framework. Your model objects automatically bind to the framework's views. You don't even need to learn or concern yourself with an API for data binding. JMatter works at a higher level. Much of the burden of validation is lifted and custom validation can be added by overriding the validate() method.
The last point wasn't too clear to me. I assume it spoke to the fact that the Swing API in general is very large, very complex, and not very consistent in many respects. It may not apply at all to JMatter since you typically rarely even interface with Swing. You might for the purpose of creating and plugging in custom views for types. This task is by its very nature somewhat challenging, but nothing that an experienced Swing developer cannot tackle.
Let's discuss the second issue: Swing is by no means a framework for building business applications. It is nothing more than a toolkit for building user interfaces. No one is certain why in the web world we have dozens of higher level frameworks to choose from and yet in the Swing world, folks have only recently begun considering the development of such frameworks.
I propose that JMatter fills this void. JMatter addresses comprehensively the task of building business solutions. Furthermore, it does so at a much higher level than most other APIs.
I recall a claim that used to be made a long time ago about the difference between a mac (i'm talking about v6 or v7) and a pc (back in the days of windows 3.1). Whether justified or not, the claim pointed out that with a mac, users typically were able to focus on the task at hand. While with a pc (at least in those days) one fiddled a lot with dos, autoexec.bat and config.sys and for the most part one remained distracted from the job they had to accomplish.
This is a major lesson about usability. Folks such as Jef Raskin wrote about the locus of attention.
I believe that JMatter frees developers in an analogous manner. We're not talking about UIs here. I'm basically saying that this framework lets developers focus on the business domain and keeps the plumbing out of their way. An apt analogy?
