velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <>
Subject Re: comparing monetary value
Date Tue, 15 Oct 2002 18:23:17 GMT
On Tuesday 15 October 2002 07:44 pm, Bill Kaufman wrote:
> > On Tuesday 15 October 2002 05:09 pm, Bill Kaufman wrote:
> > > > STham@thoughtworks.COM wrote:
> > > > >  Give a certain amount has to be less than a given value.
> > > > >
> > > > >   if ($someMoneyValue < 0.01) ???
> > > > >
> > > > >How do people normally handle money in velocity?? Thanks.
> > >
> > > There's another solution I haven't noticed mentioned: Don't use
> > > floating-point numbers.
> >
> > Bill, you seem to be saying that the solution to Velocity's
> > lack of floating
> > point numbers is not to use floating point numbers.
> No (or, that wasn't my intention).  I'm saying instead that floating-point
> numbers aren't well suited to monetary amounts, because of things like
> round-off errors and tricky comparisons involving epsilons.

Well, that's true, but there is no reason that a template engine has to use 
float or double to handle decimal numbers. In fact, as I pointed out, 
Freemarker uses BigDecimal precisely so that one has the principle of least 
surprise working in business apps.

> > In FreeMarker, we use java.math.BigDecimal by default, which
> > actually, in a sense, does what you're proposing.
> Yup, BigDecimal would be the right way to go for monetary units.  But it
> may be overly complicated, at least in Velocity today.

Well, yeah. BigDecimal has a rather awkward API to use, even from java. To 
call that API from a template does not look appropriate. In FreeMarker, you 
don't explicitly deal with the BigDecimals. They just are used behind the 

<assign x=1.12>

<assign y = 2.35>


uses BigDecimal behind the scenes. You don't go:

$myBigDecimal.divide($denominator, $scale)

or something.

> > Yeah, well, this is the thing. There are different number and
> > currency display
> > conventions in different locales. Just for starters, the
> > decimal separator in
> > some locales is a period (full stop) and in others is the
> > comma.
> That part, at least, can be dealt with generically in Java, using
> java.text.NumberFormat.getInstance() (not getCurrencyInstance()).  I don't
> know of any locale which displays monetary amount in a different format
> from other numeric values (though I wouldn't rule it out).

I don't know either, but there are a lot of locales out there. Anyway, all the 
information is built into the JDK. 

The thing is that calling these java.text.* API's from a template is rather 
awkward and (as in the BIgDecimal case) it should really happen behind the 

I don't really think that an involved java API like that is accessible to the 
kind of non-technical end-user who is supposed to be hacking a template.

> (Now that I think of it, I suspect there should be a nice way to integrate
> Java formats into Velocity,...)

Oh, my feeling is that there definitely should be. After all, one of the 
selling points of the java platform is that it allows easy 
internationalization. It seems silly to have a presentation solution that 
does not leverage all this information that is built into the JDK. That was 
part of the reason that I decided to move towards building this kind of 
functionality into FreeMarker. 

It's definitely low-hanging fruit, but whether the Velocity developers will 
ever deign to pick it, I don't know... Judging from some of the interchanges 
I've observed here, it almost seems that to propose significant new 
functionality in Velocity is akin to proposing that some new shuras be added 
to the holy koran -- or that an extra gospel be appended to the new 



Jonathan Revusky
FreeMarker-Velocity comparison doc
Velocity->FreeMarker template conversion utility

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message