Re: ConvertUtils

[Wong Kok Wai]

Similarly, I think it's better to change from

public void setDefaultBoolean(boolean defaultBoolean) {
this.defaultBoolean = new Boolean(defaultBoolean);
}

to

public void setDefaultBoolean(boolean defaultBoolean) {
this.defaultBoolean = defaultBoolean ? Boolean.TRUE : Boolean.FALSE;
}


Ralph Schaer wrote:

>
> IMHO is also better to user the Boolean.FALSE and Boolean.TRUE constants
> instead
> of creating new Boolean objects.
>

Re: ConvertUtils

[Craig R. McClanahan]

Elod Horvath wrote:

> craig,
>
> i have efficiency questions about ConvertUtils.convert...
> isn't it true that the vm loads these class object once:
> java.lang.Boolean, java.lang.String, Boolean.TYPE, etc.
>
> isn't it more efficient to just compare class objects rather playing
> with their string representations?
>

Yep ... good idea.  I just submitted a patch that implements both of your
suggestions (comparing class types and ordering the if/else chain)..

Craig

Re: ConvertUtils

[Elod Horvath]

craig,

i have efficiency questions about ConvertUtils.convert...
isn't it true that the vm loads these class object once:
java.lang.Boolean, java.lang.String, Boolean.TYPE, etc.

isn't it more efficient to just compare class objects rather playing
with their string representations?  

for example (Version 1):

if (java.lang.String.class.equals(clazz) {
if (value == null)
return ((String) null);
else
return (value);
} else if (java.lang.Boolean.class.equals(clazz) ||
   java.lang.Boolean.TYPE.equals(clazz) {
return (convertBoolean(value));
} else if (java.lang.Byte.class.equals(clazz) ||
   java.lang.Byte.TYPE.equals(clazz){
return (convertByte(value));
.
.
.

-OR (Version 2):-

if (java.lang.String.class == clazz) {
if (value == null)
return ((String) null);
else
return (value);
} else if (java.lang.Boolean.class == clazz ||
   java.lang.Boolean.TYPE == clazz) {
return (convertBoolean(value));
} else if (java.lang.Byte.class == clazz ||
   java.lang.Byte.TYPE == clazz ){
return (convertByte(value));
.
.
.


are there some issues with the class loader dumping and reloading these
class objects from memory that would make this type of optimization 
in this case dangerous or foolish?

also, since this is a big cascading if/else if statement, shouldn't
the else ifs be ordered according to the practical probability of using
a particular data type.  in my opinion, integer, long, float, and
double are probably used more often than byte and char and should 
therefore be checked ahead of them.


e
-- 
___
Elod Horvath ('e')   /  ITFAIS Records (http://www.itfais.com/)

Re: ConvertUtils

[Ralph Schaer]

Hi

I changed the ConvertUtils. Now the wrapper classes get a null value instead
of
a zero when the string is not valid. The native types get a default value,
which
is actually zero, but is changeable through a method.

Also add support for short.


Ralph

>I'm open to suggestion on alternatives.

>The problem is that there is nothing in the range of most of the primitive
types
>(byte, char, int, long) that corresponds to a "null" value for an object
>reference.  The only thing we can do is:
>* Pick one particular value to be ambiguous ("did the user
>  really type a zero or not?").
>* Throw a conversion exception, which just throws the
>  same decision back up a level.





 ConvertUtils.java

Re: ConvertUtils

[Craig R. McClanahan]

Ralph Schaer wrote:

> Hello
>
> Short comment about the ConvertUtils.convert... Methods.
> All convert methods returns zero when the String is not a valid value.
>
> Isn't this very dangerous, because zero can be a reasonable value in an
> application?
>

I'm open to suggestion on alternatives.

The problem is that there is nothing in the range of most of the primitive types
(byte, char, int, long) that corresponds to a "null" value for an object
reference.  The only thing we can do is:
* Pick one particular value to be ambiguous ("did the user
  really type a zero or not?").
* Throw a conversion exception, which just throws the
  same decision back up a level.

>
> Ralph

Craig