[jira] Resolved: (BEANUTILS-258) Improve Converter Implementations

["Niall Pemberton (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/BEANUTILS-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Niall Pemberton resolved BEANUTILS-258.
---------------------------------------

    Resolution: Fixed

> Improve Converter Implementations
> ---------------------------------
>
>                 Key: BEANUTILS-258
>                 URL: https://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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org