sign in sign up
<<
Home , Cons, Generic programming

Journal of Universal Computer Science, vol. 4, no. 1 (1998), 11-15

submitted: 25/9/97, accepted: 1/11/97, appeared: 28/1/98  Springer Pub. Co.

Java for Scienti Computing, Pros and

Jurgen Wol v. Gudenb erg

Institut fur  Informatik, Universitat Wurzburg 

wol @informatik.uni-wuerzburg.de

Abstract: In this article we brie y discuss the advantages and disadvantages of the

language for scienti c computing. We concentrate on Java's typ e system, investi-

gate its supp ort for hierarchical and and then discuss the features

of its oating-p oint arithmetic. Having found the weak p oints of the language we pro-

p ose workarounds using Java itself as long as p ossible.

1 Typ e System

Java distinguishes b etween primitive and reference typ es. Whereas this distinc-

tion seems to b e very natural and helpful { so the primitives which comprise all

standard numerical data typ es have the usual value semantics and expression

concept, and the reference semantics of the others allows to avoid p ointers at

all{ it also causes some problems. For the reference typ es, i.e. arrays, classes and

interfaces no op erators are available or may b e de ned and expressions can only

b e built by metho calls. Several variables may simultaneously denote the same

ob ject. This is certainly strange in a numerical setting, but not to avoid, since

classes have to b e used to intro duce higher data typ es.

On the other hand, the simple hierarchy of classes with the ro ot Object

clearly b elongs to the advantages of the language. It is also used to intro duce

further concepts like , which thus is fully integrated in the

ob ject oriented avor of the language and as extendeble as all other classes.

Multidimensional arrays in Javahave to b e handled as arrays of arrays. This

means that there is no guarantee that a matrix is allo cated in contiguous space.

Certainly most numerical will su er from that fact.

In a p olymorphic environment it often is helpful to get information ab out

the current sp eci c typ e of an ob ject at runtime. This can b e achieved by the

metho d getClass which returns the typ e as a constant ob ject of the class Class.

In that class metho ds to get more information ab out the or name of

the typ e are provided.

1.1 Workaround: Op erator Overloading

Esp ecially the lack of op erator overloading is annoying. It can b e overcome by

a precompiler which maps the op erator to metho d calls. Since metho ds may

return arbitrary classes this precompiler only has to change the notation of each

expression lo cally. So the corresp ondence between the original source and the

generated Java program is quite obvious. Using such a precompiler we can also

allow for the de nition of user de ned op erator names or symb ols including the determination of its precedence.

12 v. Gudenberg J.W.: Java for Scientific Computing, Pros and Cons

2 Hierarchical Programming

The paradigm of hierarchical programming means the classi cation of the data

using inheritance. Base class comp osition or programming abstract data typ es

are alternate names. We recommend to separate b etween interfaces and imple-

mentations of classes as well as to collect common b ehavior in general abstract

sup erclasses which then can b e extended for the sp eci c application. This design

leads to reusable, easily extendable classes.

The separation of interfaces and classes and the use of packages in Java

provide a go o d supp ort for clearly structured programs.

Since there is only one hierarchy of classes, we always can cast or convert an

ob ject of a typ e to its sup ertyp e. This is the usual \is-a" relation in ob ject ori-

ented inheritance structures. A conversion in the other direction from sup ertyp e

to subtyp e is also p ossible. Hence, if we know the sp eci c typ e of an ob ject, we

can make use of its particular features. These downcasts are obtained by writing

the name of the destination class in front of the ob ject. In a similar wayupward

and downward casting of primitive typ es is p ossible, where we now have the

following subtyp e relation.

int  long  float  double

Note that this relation only indicates the upward direction for casts and do es

not mean that there is no information lost, when you convert an int or long to

a float.

Metho ds are b ound dynamically by default. The mo di er final,however,

which can be attached either to a metho d meaning that this metho d can not

b e rede ned, or to a whole class which then prohibits the inheritance from this

class, op ens p ossibilities for optimization.

3 Generic Programming

The paradigm of generic programming in general deals with homogeneous con-

tainers, i.e. data structures comp osed of elements of the same typ e. These con-

tainers de ne one or several to access all or some of their elements in

a sp eci ed order. These iterators then link generally de ned algorithms to the

container. In the package java.util a simple interface is provided which

can easily b e extended to the user's needs.

This style of programming yields a high degree of reuse, since the same

structure is preserved. The data structures generally are parameterised by the

elementtyp es. The algorithms are further generic with resp ect to the iterators.

This of parametrization is usually provided by templates, a feature which

unfortunatedly is lacking in Java.

3.1 Workaround: Templates

In the language manuals it is suggested to use containers of the typ e Object

instead and p erform appropriate typ e casts. This do es not work well, since prim-

itive typ es are no ob jects, so we can not ll a container with primitive typ es.

To cop e with this situation wrapp er classes are included in the language, which

simply wrap a constantvalue of the corresp onding primitivetyp e. Since they are

ob jects, no op erations are available for wrapp er classes, not even an assignment

v. Gudenberg J.W.: Java for Scientific Computing, Pros and Cons 13

of a new value is p ossible. Hence, if wewant to write generic co de for primitive

data, wehave to explicitly check the currenttyp e and cast. This kind of co de {

a large conditional satement dep ending on typ e of the current ob ject{ has not

much to do with ob ject orientation, even if it is encapsulated in a help er class,

like NumberHelper [8]. This class provides metho ds for arithmetic op erations

for the wrapp er classes which use the prede ned primitive op erations. So this

approach only helps for the limited numb er of wrapp er classes.

We can provide a similar help er class for higher arithmetic data typ es. The

main disadvantage of this approach is that it is not extendable. If we add a new

typ e with the same interface, wehave to edit the help er class and to add a new

branch in the conditional statement.

We might try to overcome the diculty by using the runtime information

to get the name of the class of the elements and then cast to it. This, however,

can not be compiled, since the syntax requires an identi er and not a string

as a typ ename. Therefore, we write a factory class which pro duces a help er

class for each elementtyp e. The name of this help er class contains the name of

the element class. All help er classes implement one generic interface whichnow

replaces the . The application program calls the makeHelper metho d of

the factory class with an ob ject of elementtyp e as parameter. This lo oks for the

corresp onding help er class and loads it, if available. If not, it writes the source

to a le inserting the ob ject's typ e name where appropriate, compiles this le on

the y and then loads the corresp onding class. Since all help ers have identical

structure this pro cess of writing and compiling can b e made automaticly.

4 Arithmetic

Java is one of very few languages which completely sp ecify the semantics of their

oating-p ointtyp es. The IEEE 754 formats sing l e and doubl e have to b e used

for the float and double data typ e, resp ectively. All 4 basic arithmetic op era-

tions are to b e p erformed with full precision using the rounding to the nearest

neighb or. Expression evaluation has to use these basic op erations to compute

eachintermediate result, i.e. round after each op eration. This rule ignores the

facilities which some hardware units supply, like fused multiply and add or ex-

tended temp oraries, and therefore has lead to some discussion [4]. In our opinion

this feature of strict expression evaluation is mandatory for a language which

claims to get identical results on all computers. And, indeed, this goal is achieved

by that rule. So even programs using oating p oint op erations are completely

p ortable.

An interesting Java extension where expression evaluation may b e switched

between this strict mo de and a so-called natural mo de which makes use of ex-

tended hardware features and hence pro duces results which are at least as go o d,

is discussed in [3]. It will b e interesting to investigate, if the switching of arbi-

trary evaluation mo des can b e made an integral part of a language. Then other

mo des like the accurate expression evaluation of the C++ to olb ox [2] can be

incorp orated smo othly. But this certainly leads to another language.

Although Java supp orts some of the IEEE 754 prop erties there are a lot

of aws in the adaption of the full standard. Two minor ones are the lack of

any extended oating p ointtyp e and the de nition of the square ro ot function

14 v. Gudenberg J.W.: Java for Scientific Computing, Pros and Cons

without accuracy requirements. In our opinion all standard functions should b e

optimally accurate or at least sp ecify their errors exactly.

The IEEE standard provides 4 rounding mo des, but Java only knows one

of them. So it is imp ossible to call the directed roundings and hence de ne an

in the language.

One strong p ointofJava is its extendable exception handling. Surprisingly

enough the 5 IEEE oating p oint exceptions are ignored. There is no way to

enable traps for these exceptions and sp ecify handlers, or at least to check for

the o ccurrence of the exception. Only if an in nity or NaN is the result, the user

has the indication that something has gone wrong.

4.1 Workaround: Arithmetic

We derive all IEEE exceptions from the Java exception ArithmeticError.

The nativeinterface of Java allows to write metho ds in C which return java

classes and raise Java exceptions and bind them to Java programs. We exploit

these features to de ne a class FPU which has access to the underlying hardware

status. It provides native metho ds, i.e. written in C, for the arithmetic op erations

for all rounding mo des. These metho ds execute the corresp onding op eration,

read and copy the fpu state register, raise a new Java exception, if the IEEE

exception o ccurred and the corresp onding trap is enabled and then clear the

fpu state. Class FPU further provides native metho ds to , clear and test traps

or exception ags and native metho ds to set and get the rounding mo des. The

utility functions like nextAfter etc. can then b e written in Java.

Since this class has to use native metho ds, the program can only be dis-

tributed as an applet, if the external part is lo cally available, or it has to be

p orted as a stand-alone program.

The native arithmetic op erations are declared as metho ds of the FPU class,

i.e. they have 2 parameters. So it is advisable to de ne higher numeric data

typ es like IEEE_float or interval on top of these class. Wehave tried suchan

implementation and have measured a considerable decrease of eciency mostly

due to the fact that native metho ds run in a separate thread, for details see [9].

As stated in the b eginning op erators for these classes can not b e declared.

5 Conclusion

Wehave p ointed out some strong and weak p oints in the de nition of the Java

language. In the following table we give a concise overview.

Several criteria maybechecked to judge whether a language is favorable for

scienti c computing.

{ p ortability

{ eciency

{ clean and reliable oating p oint arithmetic

{ de nition of intervals and other arithmetic typ es

{ mathematical notation

If only the rst three items are considered to b e imp ortant, Javaisagood

choice. The eciency is surprisingly high and will certainly b e improved by new optimizing .

v. Gudenberg J.W.: Java for Scientific Computing, Pros and Cons 15

We, however, consider the last two items to be imp ortant and hence pro-

p osed di erent workarounds: a precompiler for op erator overloading, dynamic

generation of templates and native metho ds to adapt the oating p oint arith-

metic. Since these are relatively comprehensive to ols or exp ensive and inecient

workarounds, we cannot really recommend Java as a language for scienti c com-

putation.

topic pro con

typ e system hierarchy

primitive vs reference ob jects are no values

no op erators

no expressions

no contiguous matrices

wrapp er classes without semantics

runtime info Class

exceptions, threads

hierarchical prog. packages

classes

interfaces

nal

generic prog. no templates

typ e casts need explicit typ e id

iterator Enumeration

exception handling available not oating-p oint

arithmetic IEEE formats no extended

IEEE op erations no srqt

strict evaluation rules

no directed roundings

exceptions ignored

Java pros and cons summary

References

1. Barton,J. und Nackman,L.: Scienti c and Engineering C++, Addison-Wesley, 1994

2. R. Hammer, M. Ho cks, U. Kulisch, D. Ratz: C++ To olb ox for Veri ed Computing,

Springer, 1995

3. Co onen, J.:RealJava,www.validgh.com/jav a/re aljav a

4. newsgroup www.validgh.com/java

5. The Javatm Language: An Overview,

java.sun.com/docs/overviews/ java /java -ove rvie w-1.h tml

6. Arnold,K., Gosling,J.:The Javatm , Addison-Wesley, 1996.

7. Gosling,J., Joy,B., Steele,G.:The Javatm Language Sp eci cation, Addison-Wesley,

1996.

8. The Java Generic , www.objectspace.com

9. Lerch, M. and Wol von Gudenb erg, J.: Java for Scienti c Computing,Technical

Rep ort, Institut fur  Informatik, Universitat Wurzburg,  to app ear