Why even bother with the "long" version? I think Money should use
BigDecimal (or BigInteger... whatever) under the hood exclusively.
BigDecimal/BigInteger already have special optimizations for when they
can fit themselves in a long.
(I would more lean towards BigInteger under the hood, and usin
On Feb 13, 2009, at 4:57 PM, Stephen Colebourne wrote:
I've checked the commons-money code into the sandbox. I don't have
any time to write more code there ATM, but more needs doing before
any release. If anyone likes the code, and the idea behind BigMoney,
or formatting/parsing then pleas
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=142934&projectId=155
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 13 Feb 2009 19:23:29 -0800
Finished at: Fri 13 Feb 2009 19:25:36 -0800
Total time: 2m 6s
Build Trigger: Schedule
Build Num
I've checked the commons-money code into the sandbox. I don't have any
time to write more code there ATM, but more needs doing before any
release. If anyone likes the code, and the idea behind BigMoney, or
formatting/parsing then please go ahead and make some changes. Thats
what the sandbox is
My view is to keep it simple. I'm not sure that general I18N code has
much in common with Money.
As there seems to be some interest I'll try and check in to the sandbox.
Stephen
Ralph Goers wrote:
Is "Money" going to support I18N? I would think it would be more
appropriate to include in a co
On 2009-02-13, Wolfgang Glas wrote:
> Stefan Bodewig schrieb:
>> Reading
>> ===
>> The question is what ZipFile should assume as its default if neither
>> the EFS nor extra fields are present. This can be controlled by
>> "setEncoding" right now and defaults to the platform's default
>> en
Hi Stefan,
My comments follow.
Stefan Bodewig schrieb:
> Let me try to capture the various threads in SANDBOX-176 and from this
> list into something we can draw conclusions from.
>
> First some background:
> ==
[snip]
> Reading
> ===
>
> Let's keep ZipArchiveInputSt
Let me try to capture the various threads in SANDBOX-176 and from this
list into something we can draw conclusions from.
First some background:
==
when I implemented the ZIP classes for Ant, I was working from
InfoZIP's documentation of the format, not PKWARE's, I've now read
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-cli has an issue affecting its community integration.
This issue a
Torsten Curdt schrieb:
>> Solaris contains some special code which allows people to mark jar
>> files executable and run them as if they were native commands. It
>> will only work for jars that contain the sequence 0xCAFE (in
>> big-endian order) somewhere at the beginning, which is achieved by
>>
> Solaris contains some special code which allows people to mark jar
> files executable and run them as if they were native commands. It
> will only work for jars that contain the sequence 0xCAFE (in
> big-endian order) somewhere at the beginning, which is achieved by
> adding an extra field with
11 matches
Mail list logo
