Details
-
Type: Improvement
-
Status: Closed
-
Priority: Minor
-
Resolution: Won't Fix
-
Affects Version/s: 1.3
-
Fix Version/s: None
-
Component/s: Converters
-
Labels:None
Description
Hi.
i've noted that the some basic converters:
ByteConverter
IntConverter
LongConverter
ShortConverter
use the decode method to parse a string into a number.
Even if this is the default parsing method supported by java,
sometimes it may not be the desired one.
for instance, if your working with numbers coming from a db or from
Cobol, the sequence "009" means just "9" while the decode method,
applying the java convention that parse a sequence starting with a "0"
as a octal number, reports an exception because 9 is an illegal
character in octal coding.
Java classes offer 2 different methods with 2 differents behaviours
for parsing sequence number:
for instance
java.lang.Integer
offers
decode(String nm) , that doesn't accept a sequence like "009" ,
java.lang.NumberFormatException
valueOf(String s) , that accept the sequence "009" and translate it in
the Integer representing the number 9
do you consider to offer the choice for this 2 different behaviours,
maybe in a flavour like the class BooleanConverter which offers
preconfigurated different instances for the differents desired
behaviours?
i guess that this change could apply to all integer based converters.
thanks
paolo
Hi Paolo,
after thinking a while over this request I don't believe it is necessary. The decode method was also taken because of user request, simply because it is possible with it to decode also unsigned values as well as hex or octal values. The enhancement of the BooleanConverter for different flavors is useful because all flavors share the same code, but this is does not apply for the converters mentioned by you. You can easily register such a converter and therefore I don't think it must be already present in XStream:
Thanks for your suggestion though,
Jörg