I had a first look at both code bases. From the underlying concepts both seem to be very similar: they both have a basic interface describing a conversion/converter, factories for converters and a registry mechanism. This said it is quite hard to judge, which implementation should be preferred.
In convert2 I like the Converter class, which is an additional encapsulation of a registry. From a semantic point of view it is certainly better to use a "Converter" for conversions than a "ConvertRegistry" as in convert1. On the other hand I have some problems to see the benefits of the convert2.ConversionFactory: Because a factory is used only once to obtain a Conversion for a to/from class combination, there are not many advantages over using a Conversion object directly (I think it would be more flexible if the Conversion returned by a factory would not be stored; then a factory could return different objects based on the actual value). (And one minor detail: I think the first method in ConvertUtils should be named convert() and perform a default conversion rather than a String conversion.)
The convert1 package has the advantage that it partly deals with inheritence, which can be useful. Though when looking at the code I am not sure that the current implementation will work. Because the Converter interface is very simple it seems to be easier to implement concrete converters. In the available implementations I would somehow try to refactor out the handling of default values, maybe as a kind of decorator converter.
What I miss in both approaches is a more intuitive setup mechanism, a simple way to construct a registry from available converter implementations, though I don't have a concrete idea how to improve this either. Would it make sense to construct a default registry from a configuration file? Is it perhaps possible to use [discovery] to find converter implementations (I don't know this project very good).
Another suggestion: Depending on the actual use case it might make sense if a failing conversion throws a checked exception rather than a runtime exception, e.g. when used to validate user input. So it could be useful to add methods that throw an exception and let the client choose.
Oliver
Stephen Colebourne wrote:
I have just checked in a load of new commits in the convert2 subpackages. Essentially there are now two convert codebases in CVS, Henri committed the first based on [beanutils] IIRC, whereas I've developed the second. An external review would be good. If you could take a look at both and see what you like that would be great ;-)
Once one is picked, we can then get on and add more converters and tests, and then maybe look to a release. I'd like an early promote and release if I can manage it.
Stephen
[
Notes about convert2 package:
System is bean based - different applications can have different converters.
Each individual conversion is an implementation of a simple interface
Conversion.
The combination of a group of Conversions is a Converter.
A ConversionFactory allows Conversions to be dynamically created.
Main conversion registry is fully synchronized (as double check locking
broken).
]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
