Agreed. Memory is too constraining, I use a custom UnitFormatUtils class for
file sizes, time elapsed, and so on.
UnitFormatUtils has methods like:
/**
* Returns the given value in the format: value bytes(s).
* <p>
* For example:
* </p>
* <li>0 bytes</li>
* <li>1 byte</li>
* <li>2 bytes</li>
* <li>20,000 bytes</li>
* <ul>
* </ul>
*
* @param value
* The value to format
* @return the formatted value
*/
toByteString(long)
toMillisecondString(long)
toNanosecondString(long)
toPluralUnit(String, boolean)
toSecondString(double)
toString(double)
toString(long)
toUnitString(double, String)
toUnitString(long, String)
Gary
On Thu, Jun 2, 2011 at 11:16 AM, James Carman <ja...@carmanconsulting.com>wrote:
> On Thu, Jun 2, 2011 at 11:12 AM, Matt Benson <gudnabr...@gmail.com> wrote:
> > Implying that "memory" is an overly constraining concept to apply here.
> >
>
> Technically a buffer is typically in memory, so the concept still fits
> for that usecase. ;p However, I've actually used my toString() method
> when logging the size of files (downloading file X of size blah blah).
> So, that's not really memory. The underlying concepts here are
> "size" and binary (we're using the 1024 divisor).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
