We've developed a rather large, thin-client Swing application for Hospitals.
The client uses technologies such as Spring (dependency injection, xml marshaling, authentication etc), Groovy, SwingLabs components, log4j, ActiveMQ etc. It worked out quite well; amazingly well actually.
One of the biggest issues is deployment. We used Web Start, but the real issue is JVM deployment. We have about 1000 machines at a single hospital which then requires all of them to have an 'approved' JVM version. We got hit really hard about a year and a half ago when Sun updated their SwingWorker implementation in a minor update which hosed our entire application. I had to go back and use a version from SwingLabs and redeploy this to all our clients. Horrible bug in the Sun version which caused a deadlock. I refuse to code anything that requires a client to run on a specific minor version. Though, we do require anything post JDK 1.6u10 since there were significant additions that we relied on (Nimbus Look & Feel being one of them).
Another issue can be finding people who truly understand Swing. I didn't know it when I started. About a year after I wished I had known more before I started because I did have some design issues which would have been mitigated early if I had understood. Having a good architectural design for your app is key. It's not as cut-and-dry as a SpringMVC type application. I had been unable to find any really good application frameworks to get us started. There are some, but... So, be prepared to design your application model appropriately. Don't keep your business logic embedded in your UI code. If you are creating a fat client, build yourself an application that doesn't require a UI. If you can build an command line type interface in your application I highly recommend it. I built a debug console in ours and it has been extremely helpful in inspecting the application's state.
One major pain, that I would not do again, is incorporate Groovy into it. Groovy is just to much overhead for a responsive interface. You don't notice this on a server-side application, but you will know it when your app is just not responding as fast as you would like. Plus, we had a lot of memory leak issues with the Groovy scripting engine at the time. We incorporated Groovy because we needed to be able to customize some interface components at deployment/run-time. We created our own small DSL for this, and it was painful. I think I would now like to try Clojure, but that is just 'hey, I'd like to try it'.
Another major annoyance in Swing (or java development in general) is how much code you need to write to do simple tasks, such as responding to a button click. You will be writing a lot of anonymous inner classes (listeners/delegates) which become very cumbersome since there is just so much boilerplate in it. If only I could have had those Lambdas when I wrote it! That would have made Swing dev so much nicer. I can't even explain how nice that would be.
Another small annoyance is the lack of Generics in Swing. Some people say it's a bad idea, others want it. But, just get use to casting or creating your own generic table models. But, that only gets you so far.
Oh, and always remember that all your UI updates should be done on the event-dispatching thread!
SwingUtilities/EventQueue is your friend (when Sun/Oracle doesn't break it).
Read the docs on how cell renderers work.
There is a lot more, but it is fun.
On Dec 16, 2011, at 11:06 AM, Summers Pittman ℝ wrote:
> I've noticed that there are many of us who build web applications running Java (in my case a gigantic financial app) or work with companies who make Java libraries (in Gunnar's case Spring Source) for use in web applications. I was wondering if anyone was working on client applications? Not web applications but apps which run on the desktop (or Android or maybe an Applet) Java applications.
> What technologies do you use? What problem are you trying to solve? How is it working out?
> Summers Pittman
> >>Phone:912 293 2314
> >>Java is my crack.
> ajug-members mailing list
> ajug-members <at> ajug.org
ajug-members mailing listajug-members <at> ajug.orghttp://www.ajug.org/mailman/listinfo/ajug-members