If your code is directly calling conversion-related methods on ConvertUtils/ConvertUtilsBean to do data conversion, then you can simply change to using LocaleBeanUtils/LocaleBeanUtilsBean/LocaleConvertUtils/LocaleConvertUtilsBean instead. The Locale-aware classes will automatically detect the locale of the host machine and set up appropriate CONVERTERS for that locale. Alternatively you can explicitly create LocaleConvertUtilsBean instances providing a particular locale.

If your code is calling the property-related methods on BeanUtils/BeanUtilsBean methods, and you want the automatic type conversion facilities used to be locale-aware then you might want to look at using the equivalent methods on the LocaleBeanUtils or LocaleBeanUtilsBean classes. However because the property-related methods on these classes are not used nearly as often as the property methods on the standard (non-locale-aware) classes, they MAY not be as well debugged and some FEATURES may be missing.

A safer alternative to either of the above is to REGISTER custom locale-aware converters with ConvertUtils or ConvertUtilsBean:

LongLocaleConverter longLocaleConverter = new LongLocaleConverter(Locale.GERMAN);
ConvertUtils.register(longLocaleConverter, Long.class);
// now any call to any method on the BeanUtils or ConvertUtils classes which involves 
// converting a string to a Long object will use a LongLocaleConverter which is customised 
// to handle the German locale.

Of course the above will modify the default behaviour across the entire current application (or the current webapp if the code is running in a container environment; see the javadoc for method BeanUtils.getInstance for more information).

If you do not LIKE the idea of changing the ConvertUtils/BeanUtils behaviour so widely, then of course you can always create a BeanUtilsBean instance and customise only the behaviour of that instance:

ConvertUtilsBean convertUtilsBean = new ConvertUtilsBean();
// here, customise the convertUtilsBean as required by registering custom converters
PropertyUtilsBean propertyUtilsBean = new propertyUtilsBean();
BeanUtilsBean beanUtilsBean = new BeanUtilsBean(convertUtilsBean, propertyUtilsBean);
// now methods on the beanUtilsBean object will use the custom converters registered
// on the associated ConvertUtilsBean instance.

If your code is directly calling conversion-related methods on ConvertUtils/ConvertUtilsBean to do data conversion, then you can simply change to using LocaleBeanUtils/LocaleBeanUtilsBean/LocaleConvertUtils/LocaleConvertUtilsBean instead. The Locale-aware classes will automatically detect the locale of the host machine and set up appropriate converters for that locale. Alternatively you can explicitly create LocaleConvertUtilsBean instances providing a particular locale.

If your code is calling the property-related methods on BeanUtils/BeanUtilsBean methods, and you want the automatic type conversion facilities used to be locale-aware then you might want to look at using the equivalent methods on the LocaleBeanUtils or LocaleBeanUtilsBean classes. However because the property-related methods on these classes are not used nearly as often as the property methods on the standard (non-locale-aware) classes, they may not be as well debugged and some features may be missing.

A safer alternative to either of the above is to register custom locale-aware converters with ConvertUtils or ConvertUtilsBean:

LongLocaleConverter longLocaleConverter = new LongLocaleConverter(Locale.GERMAN);
ConvertUtils.register(longLocaleConverter, Long.class);
// now any call to any method on the BeanUtils or ConvertUtils classes which involves 
// converting a string to a Long object will use a LongLocaleConverter which is customised 
// to handle the German locale.

Of course the above will modify the default behaviour across the entire current application (or the current webapp if the code is running in a container environment; see the javadoc for method BeanUtils.getInstance for more information).

If you do not like the idea of changing the ConvertUtils/BeanUtils behaviour so widely, then of course you can always create a BeanUtilsBean instance and customise only the behaviour of that instance:

ConvertUtilsBean convertUtilsBean = new ConvertUtilsBean();
// here, customise the convertUtilsBean as required by registering custom converters
PropertyUtilsBean propertyUtilsBean = new propertyUtilsBean();
BeanUtilsBean beanUtilsBean = new BeanUtilsBean(convertUtilsBean, propertyUtilsBean);
// now methods on the beanUtilsBean object will use the custom converters registered
// on the associated ConvertUtilsBean instance.