_Original issue created by SeanPFloyd on 2010-09-21 at 09:20 AM_
A method that is often requested takes a long and formats it as x KB, x MB etc.
Here are several requests from StackOverflow (the second is mine):
http://stackoverflow.com/questions/3758606/how-to-convert-byte-size-into-human-readable-format-in-java
http://stackoverflow.com/questions/3263892/format-file-size-as-mb-gb-etc
Would Guava be a good place to implement this functionality? Perhaps in the Strings or Bytes classes?
_Original comment posted by andreas.lundblad on 2010-09-21 at 10:13 AM_
Sample implementation available at http://stackoverflow.com/questions/3758606/how-to-convert-byte-size-into-human-readable-format-in-java
_Original comment posted by [email protected] on 2011-01-27 at 06:16 AM_
_(No comment entered for this change.)_
Status: Started
_Original comment posted by [email protected] on 2011-02-15 at 10:24 AM_
Why not use FileUtils from Apache, i.e. FileUtils.byteCountToDisplaySize(long size). It was also suggested in one of the topics in the links.
_Original comment posted by SeanPFloyd on 2011-02-15 at 10:35 AM_
@锘縥ason
a) nice, thanks, didn't know that
b) hopefully, Guava will sooner or later be the reason why I no longer have to use commons/lang and commons/io
_Original comment posted by kurt.kluever on 2011-06-07 at 06:24 PM_
_(No comment entered for this change.)_
Status: Accepted
Owner: kurt.kluever
_Original comment posted by [email protected] on 2011-07-13 at 06:18 PM_
_(No comment entered for this change.)_
Status: Triaged
_Original comment posted by [email protected] on 2011-07-18 at 04:03 PM_
Comments welcome on the following take on this (surprisingly ugly) issue. I find the binary prefixes weird, but we're concerned about ambiguity (should we be?). See
http://en.wikipedia.org/wiki/Binary_prefix
Note also that we're not primarily concerned with _formatting_ here, as that might be locale- and preference-dependent. We see these classes as analogous to TimeUnit and something like a Duration.
public enum BinaryPrefix {
UNIT, KIBI, MEBI, GIBI, TEBI, PEBI, EXBI;
public long convert(long value, BinaryPrefix prefix) { ... }
}
public enum MetricPrefix {
UNIT, KILO, MEGA, GIGA, TERA, PETA, EXA;
public long convert(long value, BinaryPrefix prefix) {...}
}
public final class DataSize {
public enum Unit { BIT, BYTE };
public DataSize(long value, BinaryPrefix prefix, Unit unit) {...}
public DataSize(long value, MetricPrefix prefix, Unit unit) {...}
public boolean isBinary() {...}
public boolean isMetric() {...}
public BinaryPrefix getBinaryPrefix() {...}
public MetricPrefix getMetricPrefix() {...}
public Unit getUnit() {...}
public long getValue() {...}
}
Status: Accepted
_Original comment posted by [email protected] on 2011-07-18 at 04:04 PM_
_(No comment entered for this change.)_
Labels: Type-Enhancement
_Original comment posted by ogregoire on 2011-07-25 at 11:03 PM_
Why not use a DataSize that stays quite generic and provide two subclasses: BinaryDataSize and MetricDataSize. This way, it's still possible to keep only one Prefix enum. Conversion should be easy between Binary- and MetricDataSize.
Also, I think that the use cases for bits are too narrow. Nowadays, the "bit" (in a quantifiable context) is still used for OS distinction (32 bits-systems vs. 64 bits-systems) as well as the speed limit where the "byte" is omnipresent. I'd simply drop it. Also, if we drop the bit/byte distinction, the values may be used for any quantifiable and not only for data. Some side methods may be used to specify the data, but I'd put them in static contexts.
Finally as a side note I would use Decimal- instead of Metric- as it's quite the name, in fact (see your link).
_Original comment posted by [email protected] on 2011-12-10 at 03:49 PM_
_(No comment entered for this change.)_
Labels: Package-Base
_Original comment posted by [email protected] on 2011-12-15 at 09:45 PM_
_Issue #827 has been merged into this issue._
_Original comment posted by [email protected] on 2012-02-16 at 07:04 PM_
I'm recasting this issue as being about the data type itself -- we won't be wanting to get into the formatting and parsing of user-visible text.
_Original comment posted by wasserman.louis on 2012-04-03 at 04:23 PM_
Has anything happened with this?
_Original comment posted by [email protected] on 2012-04-04 at 03:58 PM_
We've still got a list of issues to work through on this API internally, and unfortunately we haven't prioritized doing so...so unfortunately it'll be a while till this API hits public Guava.
_Original comment posted by [email protected] on 2012-05-30 at 07:43 PM_
_(No comment entered for this change.)_
Labels: -Type-Enhancement, Type-Addition
_Original comment posted by [email protected] on 2012-09-05 at 09:14 AM_
+1 for dropping bits and/or DataSize.Unit to make scope of the calculations broader (i.e. for calculating any generic unit).
Someone had posted why one cannot use the https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/FileUtils.html#byteCountToDisplaySize(long) method.
Actually that does the opposite of what I want. If your answer is 1.4GB it simply rounds it off to 1GB as indicated in the Javadocs. This is absolutely not okay if you are showing the heapsize, remaining memory etc in a UI/admin pane etc. You simply cannot ignore 400MB in a rounding error. That is about 28% of the actual value.
This library is what I'm using:
https://github.com/JakeWharton/byteunits
Hint: spring's org.springframework.util.unit.DataSize can handle all this :D
Available since 5.1
Most helpful comment
This library is what I'm using:
https://github.com/JakeWharton/byteunits