Apfloat versions starting from 1.9.0 are supported only on Java 8 and later.
Apfloat versions 1.1 – 1.8.3 are supported only on Java 5 and later.
Apfloat versions 1.0.x are supported only on Java 1.4.2 and later.
Apfloat has been tested with various JVMs. However, historically JVMs have
been known to have bugs that may prevent some programs from running. For example,
Oracle's JVM might crash due to bug
9009053.
Other known issues
If there are temporary files (*.ap) left on your disk after running
an apfloat program, it may be because they can't be deleted at program shutdown.
If you're using Oracle's VM you may want to send Oracle some feedback regarding bug
4715154
or vote for bug
4171239 or
RFE 4724038.
If you have more than 1.5 GB of memory and you're running 32-bit Microsoft Windows, you may run
into all kinds of strange problems trying to perform calculations with extreme precision.
First, you can't have a heap bigger than about 1.5 GB.
If you set your heap to 1 GB (use -Xmx1G) or more, running out of address space
may cause further problems. Disk I/O requires mapping files to logical memory addresses. If
the maximum heap size plus the maximum apfloat temporary file size exceeds 1.5 GB you may get
a java.io.IOException: Not enough storage is available to process this command.
32-bit Linux may have similar problems.
The only good solution is probably to get a 64-bit processor and 64-bit operating system.
If you set your heap to e.g. 1280MB and try to do a 1 GB calculation, it may fail with an
OutOfMemoryError when the number should be stored in memory. This can happen
because of the heap memory arrangement. The details depend on the garbage collection algorithm
used but often the heap is divided to two "generations" (new and old) and a memory array can
only be allocated from one of these. If the "new generation" is big you won't be able to actually
allocate the whole heap for a single memory array. The solution is to specify a smaller
"new generation" size, e.g. with -Xmn8M or use a different garbage collection
algorithm e.g. with -Xincgc.
Apfloat can't autodetect CPU cache sizes. To have this feature added to Java, you can try to send Oracle some feedback on
RFE 4942707.
Some CPUs perform integer operations faster than floating-point operations, for other CPUs the opposite is true.
Depending on the CPU, you may get a small performance increase by putting this intpatch.jar
file in the classpath before apfloat.jar. Note that on some CPUs using this patch will correspondingly decrease the
performance slightly. CPUs which may benefit from this patch include Intel Pentium 3, Intel Core i3/i5/i7, AMD Athlon and AMD Athlon 64.
CPUs like Intel Pentium 4 and Intel Core 2 series perform generally better without this patch. Note that the patch
only applies to the 32-bit integer version. The old apfloat versions 1.0 and 1.0.1 use by default the "patched" code.