ABOUT CLIENT-OBJECTS FRAMEWORK

Client-Objects aims to become a collection of stable and well-organized Java libraries that help simplify the development Java client applications that extensively use JavaBeans technology. Namely, it provides means to dynamically (runtime) convert POJO classes into JavaBeans allowing the developers to use their POJO objects with binding frameworks, such as JGoodies, without the need to create JavaBeans manually.

If the information below looks too confusing, please try the tutorial here: http://code.google.com/p/client-objects/wiki/Tutorial

Assumptions About The Client-Side

One of the problems in developing Swing applications (and GUI applications in general) is binding your data object model to each other and to the GUI elements. There are excellent binding frameworks, like JGoodies Binding, and in the future Spring RCP Binding and JSR-295: Beans Binding, that are very helpful in solving this problem. These frameworks operate within JavaBeans standard - a framework that among other things describes how one could "listen" to the changes that occur in the objects that comply with the standard. The use of JavaBeans on the client-side makes sense and client-objects framework is not trying to change that.

Assumptions About The Server-Side

There are established practices in server-side coding. One of the biggest ones is the use of light-weight data objects, often called POJOs (Plain Old Java Objects), along with persistence frameworks, such as Hibernate and EJB3, for data access and transfer. These practices are justified and are in wide use. Again, client-objects framework is not trying to change that either.

So Why Do We Need Client-Objects?

Simply put, client-objects framework tries to make the above two approaches compatible. Why are they not compatible? Server-side objects - POJOs - are not JavaBeans and they cannot be used with a binding framework directly. You have to create JavaBeans objects first. Usually JavaBeans will repeat the properties of the POJOs and add property change support. If you manually write your JavaBeans you will have to update the code every time POJO interfaces change. It could also become a quite complex task when POJOs encapsulate other POJOs and contain indexed properties, e.g. arrays and collections. This is where the incompatibility is clearly seen. Client-Objects framework takes the responsibility of dynamically creating JavaBeans from the POJO instances. This is the major component of the framework.

The second major component of the framework will be a service wrapping library. Usually a service also originates on the server-side and "talks" in the POJO language (i.e. parameter types and return types contain POJOs and standard Java types). The library will allow the developer to "wrap" the services dynamically so that the POJO parameters and POJO return types become JavaBeans.

Our Priorities

• Performance. We are focusing on the GUI applications, which must be responsive and have small memory footprint.
• Stability. There is nothing worse for the user than a crashing GUI app. There is nothing more annoying for the developer than a GUI app that crashes because of a 3rd party library.
• Size. Keep the framework size (the size of the jar files) as small as possible without sacrificing the above.
• Small dependencies. Keep 3rd party dependencies to the minimum. Currently we depend only on asm and cglib libraries and hope we will not have to introduce any more dependencies. Nobody likes GUI apps that need tens of megabytes of disk space.
• Modularity. Client-Objects framework will address several aspects of client-side programming. Separate different aspects and package them in different jar files. Clearly document the dependencies between the jars.