newbe questions

[jboring]

We are evaluating Spring RCP and have a few [stupid] questions. Before getting to them, let me set the context.

- We are [very successfully] using Spring Core/Web for our web applications. We now need to build a Windows front-end to our Java [servlet-based] backend.
- We have no experience with Swing or SWT, all Java experience is with web apps.
- Some of us do have C++/MFC experience.
- Some of us have heard about the problems with Swing, e.g., that you can't build windows-native front-ends.
- Our client front end needs to communicate securely (e.g., https) with the backend.

The options as we understand them are:

a) C++/MFC based client, Spring-based / existing Java backend with a controller translation layer to convert HTTP requests
aa) C++/MFC based client, Spring-based / existing Java backend with the C++ hessian client
b) Eclipse SWT based client, Spring-based / existing Java backend with a controller translation layer to convert HTTP requests
c) Spring RCP based client, Spring-based / existing Java backend with one of the remoting options offered by Spring core.

Questions:

- Are there other options we are not aware of?
- Which option appears to be best for us?

The spring-richclient developers strongly feel the "old days" of Swing apps "not looking native" and not being performant or web-accessible are gone with JDK 1.4.2 and 1.5 and webstart. It is our belief the only problem with Swing is there are a limited number of higher-level abstractions available that assist in making the toolkit simpler and easier to use, and a limited number of design best practices. The goal of spring-richclient is to provide that.

- I gather from the statement above that Spring RCP is currently Swing-based, not SWT-based, nor will become SWT-compatible any time soon.
- Do you guys believe that SWT only offers limited advantages over Swing? Why?
- What other 3rd party GUI software does Spring-RCP integrate with that I should know about besides jgoodies-forms and TableLayout?
- I assume that all the standard Spring remoting options are available for Spring RCP?

Thanks in advance for any help you could give us.

[pdbruycker]

I don't know what the best option would be for your project, but I can answer a few of your questions:

- The standard Spring remoting options are available, because Spring RCP is built upon Spring
- 3rd party GUI software: GlazedLists and JDNC, but others can also be integrated (like JDateChooser, NachoCalender, lf2prod, ...)


Hope this helps,

Peter

[Keith Donald]

Jeff,

Yes, Spring Rich is built on standard J2SE Swing. It's important to note we exist to abstract developers away a good deal from the complexity of the underlying Swing toolkit (sidenote: some call Swing a framework, the right word for it is "widget toolkit"). The goal of these abstractions is to make it easier to build Swing-powered apps faster and in a consistent fashion -- like core Spring does for J2EE. It is not our goal to support mixing and matching widget toolkits. Swing more than fits the bill, it's the standard, and we believe building on it, not introducing more complexity by trying to support SWT, too.

As some one who builds Swing apps for a living, I can attest that Swing has gotten quite good. It's certainly is and will remain the most mature and complete widget toolkit for Java.

Unfortunately, Swing has always had a bad, misunderstood rap regarding two things: performance and native L&F emulation. In reality performance has been strong since J2SE 1.4. With J2SE 1.5 it's even better. Also with 1.5 we finally get strong native L&F emulation--e.g the windows L&F actually looks like windows.

I would recommend Swing on J2SE 1.5. I can't imagine building a new client with legacy MFC/C++ -- Java is worlds easier as a platform to develop rapidly on, and you're in the middle of a resurgence of java on the desktop.

Spring Rich integrates a number of products, and there are a number we are pursuing integration with now. These include GUI commands (a java.dev project, we leverage their design concepts and contributions in our IoC-configured GUI command framework), JGoodies Forms Layout, JGoodies Looks, JGoodies Binding (we have our own control-to-domain-object binding framework, but collaborate with Karsten in terms of API usage--we also borrow ideas from each other.), JDNC, JDIC, Spin, Foxtrot, Glazed Lists, JIDE (the JIDE team is pursuing JIDE docking integration with our application window/page/view abstractions), InfoNode (another docking framework we want to integrate with), and FlexDock (yet another windowing system.) Re: the windowing/docking integration, it's our goal to make the underlying windowing capability pluggable through a set of well defined application abstractions. This work is in progress now and will reach completion Q1 2005.

Hope this helps! Good luck on your new project!

Keith