A year after being open sourced, I am proud to say that this project is alive and active. Something I am most proud of is the JMatter community, whose presence is most felt on our mailing list. We've had many very interesting discussions and we recently crossed message 1,000. Our mailing list has slowly but steadily grown and stands today at 123 members (our developers' mailing list stands at 20 members).
As with many software projects, with time, many bugs have been discovered and squashed. Our trac issue manager documents many of them. Some were not so formally documented and are documented on our mailing list. For a detailed listing of changes, I invite you to review the project's release notes.
One of the first requested enhancements was to include a lightweight or embedded database (such as HSQLDB), so that no database configuration and setup would be required of users. Today JMatter bundles both HSQLDB and the H2 database (the default) and all six bundled demo applications require no configuration to run.
We've had approximately a half dozen formal releases. I intend to produce at least a dozen formal releases per year.
Many enhancement requests were implemented. The calendaring implementation has been recently refactored and improved (but we're not done yet). Recent calendaring improvements include:
- Making it more a seamless part of the system, so that it requires little or no configuration
- Making it more powerful, giving it the ability to easily filter events in a list view via adhoc queries, like list views work now
I have written an implementation of CSS for Swing and integrated it into JMatter. JMatter applications can now be customized and styled using CSS.
Many aspects of an application's metadata can now be specified via annotations. Many pieces of metadata were requested that didn't exist a year ago and that now have been incorporated into the framework. See the metadata section of the JMatter manual for complete details.
From the start, JMatter has embraced convention over configuration, and very little configuration was required:
- Specifying which types to persist (in an XML file)
- Specifying which types to expose to the user interface
Now, an annotation replaces the first configuration task, while the second can be performed directly from the user interface, so that configuration is optional.
We've also made progress in the direction of persisting application metadata; metadata can now be specified directly from the user interface (instead of doing this in the code). In fact, metatypes can be manipulated to some extent directly from the UI (think "turtles all the way down").
We've very recently completed the generic implementation of authorization-related services in JMatter. This means that, out of the box, you can define users, roles, and assign restrictions to roles. Commands can be marked forbidden and fields can be marked read-only or hidden. The specification and management of authorization policy can now be performed directly from the user interface.
The project has received a number of contributions from independent developers in a number of areas. Among other features, JMatter is now fully localized, thanks to Felix Torre of Spain and Marco Meschieri of Italy.
Our project now has a logo. I've recently redesigned our web site. The site runs on the excellent typo Ruby content management system. I've developed a custom JMatter theme for typo (that now incorporates the obligatory rico accordion).
Our documentation, which originally stood at 130 pages, has been expanded to more than 200 pages and has been kept up to date with changes in the framework. Furthermore, this documentation is now available in print (buy the book!). Electronic copies are freely available in both PDF and HTML formats.
We're seriously considering embracing the Groovy language in a major way. After meeting expert Swing and Groovy developer Andres Almiray at the Desktop Matters conference, I'm happy to say that Andres is actively participating in discussions on the mailing list and has committed to helping JMatter progress in that direction.
One major item that has been on my task list is still lingering: the development of a second, web-based view mechanism as an alternative to the existing Swing-based view mechanism. Such a task is not a light undertaking, as you can probably tell from the extensive amount of work that has already been invested in JMatter's current, Swing-based user interface.
The field of internet application construction is today in as much flux as ever. Ajax frameworks are maturing and now we see efforts (such as qooxdoo) to provide a complete widget toolkit that can be rendered in the browser. Some frameworks, such as Canoo ULC, are going beyond Ajax by providing the ability to remote a Swing user interface. We're also seeing the rise of rich internet application platforms such as Adobe AIR.
Perhaps in a future article we'll have an update on the status of our efforts in this area.
A Few Myths
Myth #1: JMatter Is Not Truly Open Source
Nothing could be further from the truth. JMatter is available under the GPL (see license).
Beyond licensing, the JMatter project is maintained in a truly open fashion. The various instruments necessary to run the JMatter project the open source way are in place: the project has a web site, a blog, an issue manager, mailing lists, top-notch documentation, and has had perhaps a half dozen formal releases in the last year.
A commercial license is available for those parties that, for whatever reasons, cannot accept the terms of the GPL. You'll find this commercial license to be among the least restrictive around. There are no restrictions on the number of applications developed or the scale of deployment. Furthermore the pricing for a commercial license of JMatter is ridiculously low. In fact I computed that break-even for a Java developer should be under one week, making it affordable not only for larger firms, but also for independent consultants.
Myth #2: JMatter Is a Data-Centric Product
There exist a good number of products for building database-backed software applications. These data-centric products provide a user interface for defining a schema and, perhaps, then let you define some forms for data entry; finally they provide a mechanism to navigate to each of these forms through some kind of hierarchical menuing system. It's a very traditional approach. The end result is termed a software application. These products often target non-programmers or novices. A lightweight scripting language is provided for those who want to perform more advanced customizations.
JMatter was born out of both enlightenment and need. JMatter is an object-centric system. Unlike database products, you won't find graphical tools for constructing your schema. In fact you do no such thing. You don't design forms either. And finally, no mechanism is provided for you to define a navigation hierarchy. I personally regard JMatter as being very non-traditional. JMatter targets Java developers, not novices.
JMatter is grounded in extreme refactoring. In fact, having to define a schema has problematic overlap with the definition of an object model. Having to define a user interface is likewise problematic, for the same reasons: overlap and duplication of a schema definition. Whether we like it or not, a user interface does relate a certain structure, a certain language: a schema.
One dilemma I've seen over and over again on software projects is the task of dealing with a schema change. They involve the symptoms that go along with a non-refactored solution: a single change request implies that the developer has to make changes in multiple places: the database schema must be changed, the object model must be revised, and finally, the changes have repercussions to a number of facets of the UI's implementation, which must now be revised. In fact, these problems are directly related to the accepted notion that making a change late in a project is much more costly than doing so early on.
With JMatter, you define just the object model, representing a single language for your domain. The model encapsulates more than just a schema: it's data and behavior. The other pieces: the database schema and the user interface are artifacts. They reflect the underlying model. Many benefits derive from this, and some are described in the book NakedObjects.
In fact, JMatter subscribes to many of the ideas of the NakedObjects architectural pattern. These ideas are congruent with those described by Eric Evans in Domain Driven Design. In fact, my take is that NakedObjects-like implementations make DDD a reality: they provide an implementation whereby the ideas are extended beyond design to implementation: Domain Driven Implementation.
The problem I faced perhaps three years ago with the actual NakedObjects framework is that it wasn't finished, it wasn't complete. JMatter ended up being my independent implementation of the same ideas, and has evolved from there.
JMatter provides a significant amount of leverage for developing an entire class of business applications. The framework's approach is not a rehash of older data-centric systems such as Microsoft Access, but a novel approach, one that subscribes to the ideas behind NakedObjects.
JMatter addresses what a major dilemma in our industry: that the construction of a complete business application requires a diversity of skills that goes well beyond business application development skills. It requires expertise with many much lower-level technologies. JMatter proposes to bridge this gap, and to provide the infrastructure that business application developers need to be productive, and to deliver their projects on time and within budget.
The JMatter framework has matured since being open sourced a year ago. Our community has grown and many new features have been added. I invite you to come and be a part of it at http://jmatter.org/.
See the screencast here.
Eitan Suez is a programmer living and working in Austin, Texas. He has been programming in Java since 1995 and is the author of the JMatter Framework.
Return to ONJava.