We have a set of locations within our product where BigInteger is required as the numbers can be fairly long. However, in over 90% of the cases, they are actually not that long and can be easily contained with-in a long.
Looking at BigInteger's implementation, it would be quite a waste to use BigInteger where Long is sufficient.
Would it make sense to create an Interface that has functions like BigInteger (divide, multiply, etc.) and that would be implemented by a child class of BigInteger and a class that wraps Long? Something like:
Interface: EfficientBigInteger
Class 1: MyBigInteger extends BigInteger imlpements EfficientBigInteger
Class 2: MyLong implements EfficientBigInteger (this will contain a Long, as we cannot extend the Long class)
Maybe we're in the wrong direction here?
Thanks, Yon
UPDATE: These objects (Long or BigInteger) are stored in memory for quite a while as they help us identify problematic behaviors of systems we interact with. Therefore, the memory footprint could be a problem. This is the problem we're trying to avoid. The BigInteger class has several fields (signum, mag array, bitcount, etc. etc.) which together are roughly double that of a class that encapsulates Long (taking into account the memory costs of having an Object in the first place). It means double the footprint for something we use a lot of.