We notice a third symptom when using the mathematics functions
from
the standard library. Before continuing, we should
point out that numbers in Java are not normally represented
as objects. The constant 2.0 is an instance of the type `float`

,
which is one of several built-in non-object types.
These are the only possible non-object types:
* users are not allowed to create their own*.

To parallel these, Java provides a range of built-in object types. (The naming conventions are such that the non-object types start with a lower-case letter; all object types with an upper-case letter.) It is easy to convert from non-objects to objects:

float x = 1.2; Float X = new Float( x );Here, the first variable is a number of the built-in type

`float`

,
and the second is an object of the built-in type `Float`

. The
right-hand-side of the second assignment calls the constructor method
for type `Float`

, passing it a number as argument and returning the
corresponding object.
Knowing how easy it is to convert numbers to objects, we might
expect that Java would implement `sin`

, `cos`

, and other
mathematical functions as methods of class `Float`

, enabling one to write, for
example:

Float result = X.sin();This would be consistent with the way we defined negation on complex numbers. However, here Java's attachment to the strict OOP view breaks down, and we must instead write

float result = Math.sin( x );

The reason is that `Math`

is a class defined in a
library. Its definition includes two so-called * static* methods:

class Math { static public real sin( float r ) { ... } static public real cos( float r ) { ... } }Static methods are ones whose class doesn't have to be instantiated before it can be called. So in

`Math.sin(x)`

, `Math`

is the
name of the class, not an instance of it. Java's designers, as well as
other OOP programmers, frequently use them in this way.

Mon Jan 12 14:15:07 GMT 1998