Why code Fortran programs in Java?

Too Many Primitive Data Items

by Conrad Weisert
November 1, 2011
© 2010 Information Disciplines, Inc.

This article may be circulated freely as long as the copyright notice is included.

A parallel issue

Several months ago I observed that many programs were using too many String data items. Although many of those data items were natural candidates for object-oriented classes, some programmers, especially in Java were ignoring OOP for nearly all text data.

Several readers pointed out that the exact same situation prevails with respect to numeric data. And again Java programs (and textbooks) are worse offenders than programs coded in other object-oriented languages. One observer noted: "It's as if they were coding in Fortran!"

The Java problem

It's not hard to see why, of course. Java presents serious obstacles to handling numeric classes and objects in a natural way:

Java's built-in numeric types (int, char, double, etc. are primitive data, subject to restrictions that constitute almost a separate language from the reference language that deals with objects.
In particular as we observed when Java was new, objects of a numeric class, such as Money or Weight cannot be used in ordinary easy-to-read numeric expressions.
The so-called wrapper classes that allow primitive data to be manipulated as objects circumvent a few restrictions, but don't contribute at all to being able to define a sensible, say, Distance class.

Bjarne Stroustrup, the principal designer of C++, advised long ago: "Provide as good support for user-defined types as for built-in types." The Java approach has been almost the opposite: Make user-defined types as incompatible as possible with the core Java language.

Making the best of it

So, many programmers using Java, when confronted with those obstacles, just conclude that it's easier to forgo numeric objects altogether than to struggle with ugly work-arounds. Experienced software engineers disagree, however. Although the expression syntax is ugly and you have to go to a good bit of extra trouble in Java to define a numeric class, object-oriented technology still offers major advantages in programming productivity and software reliability. For example:

Units integrity—If the program divides a Distance object by a Time object the result will automatically be a Speed object in the proper units.
Dimension integrity—The program won't produce square dollars if it multiplies price by commission instead of by commissionRate.
Range control—The program won't be able to compute a Temperature in negative degrees Kelvin or an Angle exceeding 360 degrees.

Furthemore, once those numeric classes are developed and made available in a library, future application development, compared with using raw floating-point numbers, will be both faster and comparatively free of computational bugs. There is no downside to using classes and objects to model numeric data.

What sorts of numeric data should not be objects?

A thorough treatment

Object-Oriented Computation in C++ and Java, ISBN 978-0-932633-63-7, explores the definition and handling of numeric objects in depth.

Even when we exploit object-orientation to the fullest degree, we still have needs for pure numbers, and the primitive built-in types work well. Abstract quantities such as loop counters or dimension specifications are most clearly and most efficiently given as int. Convergent series and numeric integrals are usually evaluated with double variables. Intermediate results in a complicated calculation may nor belong to any useful application-domain type. Those data are most naturally and most simply represented by pure numbers.

But as a general rule, if the data item has a unit of measure it's a candidate for a class definition in any object-oriented programming language, even Java.

Return to table of contents
Return to technical articles

Last modified November 1, 2011