Uploaded image for project: 'Commons BeanUtils'
  1. Commons BeanUtils
  2. BEANUTILS-258

Improve Converter Implementations



    • Improvement
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • 1.7.0
    • 1.8.0
    • None


      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.


        Issue Links



              niallp Niall Pemberton
              niallp Niall Pemberton
              0 Vote for this issue
              1 Start watching this issue