Surveying new territory
My current project has certainly proven to be a refreshing change. After countless projects in large organizations, culminating in experiencing enough red tape to seemingly circumvent the globe, working on project as part of a small team more capable of responding to feedback has been a breath of fresh air.
Swingin’.
*Thankfully* I’m finally working on an application whose primary interface is a rich Swing UI. Virtually all my web development experiences have attempted to mimic rich desktop interfaces in some way. The resounding belief among technicians on these projects was that the wrong UI was being employed for the task. It seemed ease of deployment and the trend towards web applications were the foundation for UI selection. Before the AJAXers of the world arc up, yes AJAX widens the scope of applications suitable for a web interface, but desktop applications will always have their place - I can’t see an advanced word processor being replaced by a web application anytime soon.
So it’s been a flashback to the heady days of Applet development via AWT, my original experiences in the Java landscape. During the experience I’ve been surveying the OS community for frameworks assisting with Swing development. Surprisingly, Swing hasn’t been impacted by a ‘Struts’ framework like web development has. It seems most OS efforts continue to be in handy UI components such as file choosers and tree views, the same sorts of components that were being sprouted for Delphi and C++ Builder many years ago.
It seems a handful of potentially useful Swing specific tools have sprouted though - Foxtrot and Spin address management of Swings event dispatching thread. Some tools compose UI’s via XML, lessening the burden of composing complex component layouts. Others offer trivial infrastructure to somewhat simplify event management. Still, none seem to offer significant value above sound OO concepts. It seems you could roll your own infrastructure to do similar jobs in a relatively short amount of time.
PicoContained.
One of the first principles I’ve instilled on my new assignment is the elimination of Lookups and Singletons in favour of Dependency Injection. To that end we initially employed PicoContainer, using NanoContainer to support an XML configuration. After the initial grief of discovering NanoContainer’s poorly documented schema, I soon encountered some nasty bugs in PicoContainer’s heirarchcal container features. So I chose to replace PicoContainer with a purpose built container, taking all of 1 day to complete. I appreciate that PicoContainer is a project that now accommodates many languages and means of configuration, but from my experience an ultimately limited set of it’s functionality is put to use. So much so that rolling your own implementation to accommodate your circumstances turns out to be a reasonable proposition.
Java Deprecated Objects (JDO).
Unfortunately, the team has inherited JDO as our persistence technology. Surely the best reason an organization could have to use JDO above other ORM tools (i.e. Hibernate) is that they made a significant investment in an initial implementation. In any other circumstance, given the controversy of overlapping JDO and EJB specifications that lead to delays in the acceptance of the JDO 2.0 specification, wiser heads would seek alternative persistence solutions. To a large degree I already consider the JDO specification deprecated, waiting to be superseded. Sure, if you’re already using it, maybe it’s easier to move with it. But if you have no legacy considerations, why choose a technology that’s already dated, especially given better solutions to the problem of persistence are available?
I have a couple of gripes about JDO’s API:
- The API is bloated. The key class (PersistenceManager) contains 55 methods. Granted, a fair amount of that is convenient function overloading, but the result is a cumbersome API.
- I really dislike the concept of ‘live’ objects. I much prefer explicitly saving an object. The JDO team seem to have acknowledged that some prefer this approach by introducing detach and attach features.
Granted these gripes are relatively minor and plenty of people have used JDO successfully for their persistence needs.
Big Mac.
So I’ve now had 2 weeks using a dual CPU Mac with Tiger for 9 to 5 use (ahhhh….it’s a tough life). The experience was pretty cool, but I encountered my fair share of problems. Above the usual keyboard layout complaints, here’s a few others:
- IntelliJ’s key bindings needed some serious surgery. Above the changes made by the IntelliJ team to accommodate not being able to use the first few function keys in Mac apps, there were a couple of key bindings out-of-the-box that plain old didn’t work. Some examples: F9 to resume a debugging session, and what the heck happened to Alt+D to ‘Do Refactor’? In all I’ve probably changed about 50ish key bindings to date.
- Why not support the Windows convention of using Ctrl for editor actions, like Ctrl+C for copy? I appreciate that traditional Mac users are acustomed to using the Mac key so it needs to be supported, but for cross-platform apps (i.e. IntelliJ) to not support both a generic and Mac specific keymap is madness. Admittedly, I’m being fanatical on this point as I’m a Java developer who changes operating system frequently.
- Running a headless JVM ends up presenting *** Attention *** Please attach debugger. Press any key to continue….. Nasty.
Still, 2 weeks and I’m just about hooked. The ‘eye candy’ factor is significant as well, it seems when I look at a Windows installation now, my first impression is that it’s, well….pixcelated.
July 6th, 2005 at 3:08 am
Sounds like a great contract. I’d be interested in seeing how you guys are using JDO in your app. Are you using JDO from within your swing client? What kind of caching technologies are you using? It’s good to see there are still some Java programmers willing to build their own when necessary instead of throwing in frameworks for a little bit of functionality.
If you search the IntelliJ EAP forums you’ll find some key bindings for OS X.
After you’ve played with swing for a while you should check out Objective-C/Cocoa. I find it much easier and faster to build GUI applications (of course the result will be Mac-only). If you like dependency injection you’ll love delegates and bindings in Cocoa. I’m surprised Java/Swing hasn’t taken on more of these ideas.
July 11th, 2005 at 3:36 pm
Did you also consider Spring when you found out that pico container did not work that great? From our experience so far Spring is really reliable and we haven’t found any bugs in it yet.
Apart from this, dual-processor Mac? I am jealous!
Cheers
Erik
July 11th, 2005 at 7:51 pm
Hey Kham. Thanks for your comments.
I recall from a discussion we had some 2 years ago (when JDO first hit the Persistence scene) you were looking into or already using it.
Yes, we are using JDO within both a Swing client and Servlet container. Subscribing to addressing performance if and when it becomes an issue, we haven’t needed to look into caching yet. Our currently limited performance tests haven’t highlighted any areas of concern, but we are in the early stages of development.
I’ll be sure to take a look at Cocoa, although platform independence is a requirement for the Swing app. Mac app development is a hot niche at the moment (i.e. Get Rich Writing Mac Apps, http://developers.slashdot.org/article.pl?sid=05/07/04/1116230&tid=181&tid=8). Interestingly, Apple recently announced it was giving up on the Cocoa Java API (http://www.osnews.com/story.php?news_id=11165), although it kinda defeats the purpose of using Java if you’re already locked into an operating system.
July 11th, 2005 at 8:13 pm
Hey Erik. I considered a few open object containers, obviously PicoContainer as well as Spring and HiveMind.
I chose Pico for a few reasons:
1. The API was Class/Interface centric. I certainly prefer services to be tied to Interfaces vs. names like Spring’s BeanFactory.
2. I liked PicoContainer’s container heirarchy concept as a means of dividing what can turn out to be bloated configuration files.
3. Pico’s configuration files were the least verbose (especially vs HiveMind).
4. Not because a ThoughtWorker was/is the most prominent contributor!
One other minor point, I’ve heard you can download Spring’s BeanFactory API separately - anyone know the location of this jar? I certainly wouldn’t consider using an API weighing 100’s of K for relatively trivial functionality.
July 28th, 2005 at 4:21 pm
Hi Matthew,
I do not understand the first remark. In particular, services themselves can remain ignorant of that they are part of a Spring bean factory or application context.
As to your second point. Spring also supports subdividing configuration files into several different ones and also supports the concept of parent/child application contexts. E.g. when you look up a bean you first look in the child and if it does not exist there the lookup goes to the parent. So hierarchy is there.
As for the Spring jars. Spring offers one big jar with everything or different smaller jars for parts of the functionality. For the bean factory you need to use the spring-core.jar and spring-beans.jar according to the docs.
Cheers
Erik
November 20th, 2005 at 3:22 pm
Hey Erik,
In retrospect my initial response to your suggestions were fairly ignorant.
I was under the impression that Spring ‘beans’ resolved dependencies with other beans via property names and not interface types. Certainly all examples I encountered suggested this. I now understand that it has ‘auto-wiring’ capabilities for resolving dependencies matching an interface type (if there is only one implementation configured). It can also inject via constructor (inspired by Pico-Container) as well as bean properties.
You are also correct in stating that it supports division of configuration among many files.
And you are also correct in stating that you can use a select few jar files (J2EE Development Without EJB suggests you only need spring-core.jar and commons-logging.jar) if you only require the use of Spring’s lightweight container. I was confused on this point as you need to download the lot and take what you’d like, rather than selectively download the parts you need.
If I had my time again, I would certainly attempt to use Spring after giving up on Pico-Container, and only then roll my own lightweight container if none suited my needs. That said, it was a worthwhile learning experience - writing what turned out to be a heirarchical lightweight container with AOP-like declarative services via CGLib (not that thats a good excuse to implement a proprietary solution of course).