Guava: DataSize class that represents a particular amount of data (e.g. 1 Gigabit, 2 megabytes, etc.)

Created on 31 Oct 2014  路  20Comments  路  Source: google/guava

_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?

P3 package=base status=triaged type=addition

Most helpful comment

This library is what I'm using:
https://github.com/JakeWharton/byteunits

All 20 comments

_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 ogregoire on 2011-02-15 at 10:48 AM_


Will various locales be supported?

_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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

epkugelmass picture epkugelmass  路  4Comments

Bocete picture Bocete  路  3Comments

dongritengfei picture dongritengfei  路  3Comments

Lysergid picture Lysergid  路  4Comments

terence1984 picture terence1984  路  3Comments