No PropertyEditor for java.lang.Boolean available [SPR-135]

[spring-projects-issues]

Matthew Sgarlata opened SPR-135 and commented

Spring contains a PropertyEditor that allows Spring to automatically populate boolean properties of JavaBeans, but doesn't have a PropertyEditor that allows for automatic population of java.lang.Boolean properties using the same syntax. This property editor would be useful if you want to force a user of a class to configure a Boolean property before the class can be used (rather than specifying default values for the boolean property, which is required if you are using a primitive boolean).

I can provide a use case for this behavior and a stack trace of the error if needed.

---

Affects: 1.0.1

[spring-projects-issues]

Juergen Hoeller commented

Primitive types are automatically covered by the standard JavaBeans infrastructure of the JDK; however, their object counterparts are not.

Beyond the standard JavaBeans editors, Spring provides a selection of additional PropertyEditors in the org.springframework.beans.propertyeditors package. Most of them are automatically applied by BeanWrapperImpl.

In the case of java.lang.Boolean and all java.lang.Number subclasses, the corresponding editors are not registered automatically. The main reason is that it's not clear how to parse an empty String value: Is that an invalid value, or does it indicate setting the property to null?

The corresponding PropertyEditors are CustomBooleanEditor and CustomNumberEditor. You can easily register those with a BeanWrapper or a DataBinder via the respective "registerCustomEditor" methods, for example in the "initBinder" callback of a command/form web controller.

CustomNumberEditor and also CustomDateEditor (for java.util.Date) allow for localized resolution of String values, via given NumberFormat respectively DateFormat instances. This is particularly important for binding request parameters in a web environment.

For bean definitions in an application context, you can implement a BeanFactoryPostProcessor that registers custom PropertyEditors. There's also a prebuilt CustomEditorConfigurer that allows registration of an editor bean per type.

Juergen

[spring-projects-issues]

Matthew Sgarlata commented

My opinion is that Spring could guess that an empty string should be treated as a null and true and false should be considered true and false, respectively. I think this behavior would make the framework a little easier to use out-of-the-box. The definition could always be overriden in the application's configuration if needed. I think there is precedent for frameworks making choices like this that will fit most situations, but still allow advanced users to customize behavior if necessary.

[spring-projects-issues]

Andreas Senft commented

Just a remark: Why bothering about empty strings? There should be now the possibility to use \ to indicate a true null reference.

Beside that, I would also agree on providing default editors for Boolean and Number types, using the same format as the according primitives. That should be pretty intuitive and can be overridden if needed.

Just my 2 cents. Andreas

[spring-projects-issues]

Juergen Hoeller commented

Added default editors for Boolean and Number objects, basically using special incarnations of CustomBooleanEditor and CustomNumberEditor. CustomNumberEditor uses Integer.valueOf/toString etc for parsing/rendering in this case, rather than a NumberFormat.

Juergen