The Sun CLDC Java specification is intended, amongst other things, for mobile phones and PDAs. The introduction to the CLDC specification from Sun dated May 19, 2000 states in its introduction that "Cell phones, two-way pagers, personal digital assistants (PDAs), organizers, home appliances, and point of sale terminals are some, but not all of the devices that might be supported by this specification". It specifically outlaws support for floating point. Section 4.1 says that "This means that a JVM supporting CLDC shall not allow the use of floating point literals (JLS 3.10.2), floating point types and values (JLS 4.2.3) and floating point operations (JLS 4.2.4). Section 5.1 states that "Floating point support was removed because the majority of CLDC target devices do not have hardware floating point support, and since the cost of supporting floating point in software was considered too high."
Support for PDAs includes Palm Pilot O/S devices. If you look at the available applications for these devices, you will see that many of them use floating point. This includes calculators, spreadsheets, and a variety of small applications that are basically small domain-specific calculators. In my case, I wanted to write a small statistical analysis program, capable of calculating exact significance and confidence regions for a few non-parametric statistics. This is difficult to do without floating point: even fixed point isn't good enough, if you want the program to be able to provide accurate probabilities for events that are of very low probability under the null hypothesis.
To cope with this, I have written a small floating point class for CLDC, which is just comprehensive enough to be used for my purposes. It does not provide compliance to ANSI/IEEE 754: even neglecting the fact that it provides only a few of the facilities listed there, it does not provide the precision required there either. Neither has it been tested to production standards. I believe that other programmers will end up writing similar classes again and again, and that the production of a proper floating point class is a project useful enough, large enough, and specialised enough, that it should be done as part of the MIDP supporting libraries.
Providing a floating point class as part of the MIDP standard would also allow MIDP implementers to substitute an implementation using native methods for a pure Java implemention when convenient, for instance, if the operating system for the device included a software emulation of floating point. This would considerably improve the performance of floating point client code on that platform, without hindering portability. The classes, native or otherwise, would only contribute to the size of applications that actually used them. To aid in such a substitution, I have designed two interface classes supporting floating point calculations. One is a factory interface that can create objects implementing the second interface, which contains the main floating point operations. It is therefore possible even to use multiple different implementation of floating point in the same program. As a demonstration, I include an implementation of the floating point class that uses Java doubles, as well as the one I developed to use Java ints and longs, that can actually run on CLDC JVMs. This allows routines originally developed for CLDC Java to run efficiently under a standard JVM.
Since this code is not of production quality, I believe that its most valuable contribution is to propose an interface that can be tested in real programs. Click here for the Javadoc of the main interface, and here for the Javadoc of the factory interface.
This Jar file contains the source of the classes involved, and their test program. Because this includes an implementation of the interface based on Java doubles, it includes .java files that cannot be compiled under MIDP. (I rename .jar files to .zip to stop the Demon webserver ASCII-converting them).
This jar file contains the source of the statistical application described above (duplicating the .java files required to provide floating point under CLDC), which demonstrates at least that after cutting away the Java doubles, you can compile and run the classes under MIDP. Unfortunately, it also demonstrates that, this application (which requires a considerable amount of calculation) is far too slow to be practical, at least on a Palm m105.
You are free to copy and/or use any and all code presented here, (at your own risk!) for all purposes, but I would appreciate an acknowledgement if you do so.