Silver Mind Software has released Hitch Swing Binding API 1.0 under the Apache 2.0 License. Hitch simplifies the translation of values between Swing JComponents and JavaBeans/Maps. It accomplishes this through an explicit or automatic configuration that defines how and what properties and components are to be bound. The bean/map(s) that the JComponents bind to are referred to as the “Model”. The collection of JComponents that are used to collect data are collectively referred to as a “Form”. NOTE: If you are familiar with web based development the concept is similar to an html form that passes it's values into a bean. Once the configuraiton is in place values can be passed between the form and the model through a simple method call to Binder.populateForm or Binder.updateModel. Features:

• Annotation and programmatic configuration
• Binding to POJOs and Maps
• Auto Binding to POJOs
• Pluggable Component Handlers and Type Handlers

what is the relation between this and beansBinding? are they compatible?or intend to be compatible,are them even comparable why should i use it instead of beansBinding 0.6(current version)?...what is your selling point?

The only thing i have seen on JSR295 was a page on a blog and a JSR with no spec. So, I can't really answer your question. Hitch was built to address the needs i had when developing in Swing (scratched my own itch). It's goals were to keep things extremely simple so that it could be hand coded easily. I'd be happy to provide an analysis of the differences if I had something to compare with. Feel free to post a link to a manual or specification that i can review. Thanks for the post and question.

you can find an early implementation of beansbonding in http://beansbinding.dev.java.net ,there is some blog entries that explain it and there is a session on javaOne about it (java one sessions now available online on developer.sun.com/javaoneonline)

i have to confess that it is super simple (than the jsr295) to use for simple property binding but there is some questions: 1-what is the naming convention for autobind other than the same field name ?can i auto bind private String name; to private TextField nameTextfield; 2-what is your null handling strategy,throw exception or justr ignor the field,or reset to some default value? 3-can i bound to tableModel or treeModel (a feature in the jsr295) and populate and updateJTree and JTable? thanks for the good work joe

what is the field search strategy? does the binder search the component hierarchy or search the field in the given class? if it search components as fields in the given class,why should the binder.updateModel amd binder.populateForm use a container as a parameter not a sinple Object,this limit my design as i have to always inherit from a component and i does not follow that pattern instead i use simple pojo and declare the container in it and attach all my components to it(i prefer delegation than inheritance)

Currently the field search strategy examines the passed in class and all of it's super classes. I do not use a delegation model in my normal development. However, I think it is a sensible approach. I'd appreciate a simple working example of your approach. I'd be willing to adjust Hitch to allow for this scenario as well. It doesn't sound as though it would be too difficult.

1) Currently the only convention that is supported is the identical naming of a component field and model property. If the "field + component type" combination is a common convention, I think it would be reasonable to add that. 2) There are two sides to null handling. a) Null Handling from model property to form component: If the component can support a null then it will be passed along. In cases like JTextField a null will be converted to "" simply because it is unlikely the actual string "null" will want to be presented. b) Null Handling from form component to model: When attempting to bind from a form component to a model property it will depend on the type being bound to. If the component produces a null and the type can receive a null it will pass the null along. c) Further on this point the ComponentHandler/TypeHandler implementations for each component/property will define how nulls are handled in each direction. Mostly we strive to avoid throwing exceptions by handling nulls intelligently. I need to expand the documentation to explain how to implement custom TypeHandlers and ComponentHandlers. In the meantime the Javaodc on the ComponentHandler interface provides the best documentation. The TypeHandler interface is fairly self explanatory. 3) Currently Hitch does not support binding to Tree Models or Table Models. We found Tree Model requirements to be less easy to define a standard on. On top of that we found that tools like GlazedLists are much more effective for this kind of requirement. I'm not opposed to including something like this in Hitch. I just haven't run across a scenario where it seemed like a good fit. I'm excited about receiving feedback and improvement recommendations that can be applied to Hitch. Feel free to drop an improvement ticket into the hitch issue management (http://hitch.silvermindsoftware.com/newticket) if you feel like there are features that should exist.

I've been seeing more and more Swing binding frameworks come out lately, which is a good thing in my opinion. I've been developing a Swing client for a few years now, and while a new web development framework seems to appear every day, comparatively little activity has been seen in the Swing realm. BTW, I just ran across another project which looks VERY promising (though I haven't really dug into it yet): http://genesis.dev.java.net/nonav/3.0/maven-site/en/index.html

genesis may be good but i really think hitch is much more simple ,powerfull and natural to use as it doesnot enforce you to a certain model of programming i hope one of the team answer my previous 3 questions thanx

Looks promising, but I'm already quite pleased with JGoodies Binding