[ http://issues.apache.org/jira/browse/BEANUTILS-258?page=comments#action_12449255 ] Henri Yandell commented on BEANUTILS-258: -----------------------------------------
The date conversions go via a long milliseconds variable, so timezone data is going to be lost for Date + Calendar as input. > Improve Converter Implementations > --------------------------------- > > Key: BEANUTILS-258 > URL: http://issues.apache.org/jira/browse/BEANUTILS-258 > Project: Commons BeanUtils > Issue Type: Improvement > Components: ConvertUtils & Converters > Affects Versions: 1.7.0 > Reporter: Niall Pemberton > Assigned To: Niall Pemberton > Priority: Minor > Fix For: 1.8.0 > > > The "Converter" contract has the following signature.... > public Object convert(Class, Object) > ...which incudes the type (Class) that the value should be converted to. > However all the Converter implementations in BeanUtils ignore this parameter > and always convert to a specific type - for example IntegerConverter only > ever converts to Integer values. > One of the weaknesses in BeanUtils is that conversion of an Object to a > String is almost always done using the toString() method which, depending on > the Class, can produce unhelpful values. IMO all Converter implementations > should, at a minimum, support also support conversion from the type they > handle to a String. > Theres two stages to this process: > 1) Enhance Converter implementations to handle conversion to Strings. > 2) Modify BeanUtils/PropertyUtils to delegate String conversion to the > Converters. > In order to facilitate this, I'm adding a new AbstractConverter class which > removes the need for duplciated "boiler plate" code. As well as providing a > structure for conversion it also handles missing and invalid values in a > uniform way. > I also have new NumberConverter and DateTimeConverter implementations which > provide improved String conversion facilities: > 1) Number Conversion > The existing number Converter implementations use String handling functions > provided by the Number implementation. This has two main drawbacks - they > don't handle String values containing thousand separators and they are fixed > using a period (".") as the decimal separator making them only usable in > Locales where that is the case. I'm adding a number Converter where a pattern > can be specified for the format and/or a Locale specified to use different > decimal symbols. This caters for the alternative Locale scenario and isn't > intended to provide support for applications operating in a multiple Locale > environment. > 2) Date/Time Conversion > Currently there are only implementations for the java.sql.Date/Time/Timestamp > types - java.util.Date and java.util.Calendar are not handled. I have a > date/time Converter implementation that caters for all of these types. As > people have indicated elsewhere converting from Strings to Date/Calendar > poses problems. This implementation can be configured either to use the > default format for a specified Locale or can be configured with a set of date > "patterns". This may not fully satisfy String <--> Date conversion > requirements, but will at least provide something and importantly will > provide Date conversion factilities where String is not involved (e.g. Date > <--> Calendar). > 3) Array Conversion > I also have a generic array Converter implementation. It can convert to/from > Arrays of any type. It does this by delegating the element conversion to a > Converter of the appropriate type. As well as that it also caters for > Collection --> Array conversion and provides addtiona configuraton options > for parsing delimited String. > I'm going to start committing the changes to the Converters initially. If > no-one objects to those, then I'll start looking at improving how > BeanUtils/PropertyUtils uses/delegates to Converters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]