CERN European Laboratory for Particle Physics

CERN Note 99-001 (CO)

Use of in the CERN Accelerator Environment

A Technical White Paper on Java

Document prepared by: R. Billen, E.L.Casado, M.Vanden Eynden

On behalf of the Java-GUILS project team: M. Alvarez, R. Billen, E. L. Casado, J. Courthial, R. Hoh, R. Martini, P. Nouchi, G. Smith, M. Vanden Eynden, .Watson

March 1999 Table of Contents Table of Contents...... 2 1. Preface...... 3 1.1 Readership ...... 3 1.2 Objectives...... 3 1.3 Java-GUILS Project Background...... 3 1.4. Acronyms, Abbreviations and Definitions...... 3 2. Object Oriented Technology and Java Training...... 4 2.1 Courses ...... 4 2.2 Books...... 5 3. Java Development Environment ...... 5 3.1 Platforms ...... 5 3.2 ...... 5 3.3 Editor...... 6 3.4 Development and Runtime Environment...... 6 3.5 Java Classes ...... 6 3.6 User Building Tools...... 7 4. Object Oriented Analysis and Design ...... 7 4.1 Need for It...... 7 4.2 Unified Modelling Language...... 7 4.3 Modelling Tools...... 8 5. What Protocols for Building Distributed Java Applications? ...... 8 5.1 Communication Architecture...... 8 5.2 Database Access...... 9 6. General Issues...... 10 6.1 Central Repository and Support ...... 10 6.2 Communication...... 10 6.3 Documentation...... 10 7. Java Critical Issues...... 11 7.1 Java Availability...... 11 7.2 Java Performance ...... 11 7.3 Java Portability...... 12 8. Pros and Cons of Java ...... 12 8.1 The Advantages of the Java Language ...... 12 8.2 The Drawbacks of the Java Language...... 13 9. Conclusions and Recommendations...... 13 References...... 14 1. Preface

1.1 Readership This White Paper compiles the experience gained during the Java-GUILS Project [ref 1] with the Java technology in the CERN technical accelerator environment. The target audience is technical and project managers and developers who are considering to implement Java technology in their software environment.

1.2 Objectives The objectives of this document are: x To explain the benefits and drawbacks of Java with respect to "traditional" software languages. x To give guidelines to define and set up the correct Java Development environment. x To elaborate the need for object oriented modelling methods and tools. x To discuss some commercial products and standards. x To demystify the myths of Java such as portability and performance. x To provide a basis for making the Java decision. x To provide common sense tips when using Java. However, the information provided in this document is helpful but not sufficient to decide on the use of Java technology in future software projects. Such decision but will depend on the specific requirements and constraints of each project, as well as on the evolution of Java.

1.3 Java-GUILS Project Background The purpose of the Java-GUILS project was to provide a generic, platform independent tool to visualise and analyse CERN operational data. This tool would replace the existing Graphical for the Logging System (GUILS) written in Pro*C and X/Motif. For platform independence and technology investment reasons, the project was to be developed with the Java technology. The Java-GUILS project was intended as pilot project for the use of the Java technology in the CERN technical accelerator environment. Therefore, this White Paper on Java was an important deliverable of the project. The project was officially launched in February 1998 and was foreseen to end in December 1998. The project team was composed of eight members from the CERN divisions SL, PS, ST and LHC, led by R. Billen (SL/OP). At the end of 1998, the estimated manpower resources put into the project are two man-years and only marginal financial resources. At that time, a working Java-GUILS tools was available on the PC platform as a beta release. Work still needs to be done in order to satisfy all user requirements, solve the existing software bugs, improve speed performance, endorse user friendliness and make the tool operationally available. Nevertheless, as a pilot project, the result is extremely encouraging.

1.4. Acronyms, Abbreviations and Definitions API Application Programming Interface AWT Abstract Window Toolkit C C programming language C++ C++ object oriented programming language CERN European Laboratory for Particle Physics CORBA Common Object Request Broker Architecture CPU Central Processing Unit FTP File Transfer Protocol GUI Graphical User Interface GUILS Graphical User Interface for Logging Systems HP-UX Hewlett-Packard Operating System HTML HyperText Markup Language IT Information Technology Java-GUILS Java Graphical User Interface for Logging Systems JDBC Java Database Connectivity protocol JDE Java Development Environment JDK Java Development Kit JFC Java Foundation Classes JIT Just-in-time JRE Java Runtime Environment JVM OMT Object Modelling Technique OO Object Oriented OOA Object Oriented Analysis OOD Object Oriented Design PCR Prevessin Control Room RDBMS Relational Database Management System RMI Remote Method Invocation RPC Remote Procedure Call SASD Structured Analysis Structured Design SQL Structured Query Language SQLJ Structured Query Language Java UML Unified Modelling Language URL Uniform Resource Locator

2. Object Oriented Technology and Java Training In order to start developing Java software, it is vital to be acquainted with the Object Oriented (OO) paradigm. Especially for software developers with a "traditional" education in languages such as C and methods such as Structured Analysis & Structured Design (SASD) [ref 2], a mental leap needs to be overcome to Object-Orientation. Concepts such as objects, classes, encapsulation and inheritance and their implications should be well understood. In addition to these concepts, the analysis and design of OO architectures requires also some training and experience. Courses on OO Analysis (OOA) and OO Design (OOD) must precede those on Java as an OO language in order to concentrate first on the mechanics of building OO software systems (e.g. requirements capture, use cases, conceptual models, system sequence diagrams, etc.). It is not sufficient to learn the Java language, an important intellectual investment is required to get familiar with the OO approach and the high level of abstraction. The primary goal is to have an investment in OO methodology, independent (down to the design phase) of the Java language. The choice of Java as implementation language, in favour of C++, is based on the ease of use, the modern evolution and the wide support of Java.

2.1 Courses At CERN, several courses on OO and Java are held regularly [ref 3]: x Object-Oriented Analysis and Design: a 3-day introduction to OO software engineering. x An overview of the Java programming language: a 1-day general introduction to Java. x The Java programming language (Level 1): a 2-day course describing OO concepts and basic Java syntax. x The Java programming language (Level 2): a 3-day course describing the Java Development Kit (JDK) libraries.

Specific courses for additional insight on the use of Java in network programming, web, JavaBeans and the latest Swing libraries are also available at CERN. For a specific Java project, one might consider organising a condensed 3 days course, instead of the 5 days level 1 and level 2. The course can then be tailored to the actual level of the trainees and concentrated on specific needs for the project. At the start of the Java-GUILS project [ref 1], such a condensed course proved to be very effective for the developers on the team.

2.2 Books Following books are considered as genuine references in the universe of OO and Java: - Java in a Nutshell - D.Flanagan - O'Reilly - Applying ULM and Patterns - G.Larman - Prentice Hall PTR - Core JAVA - Cay S. Horstmann & Gary Cornell - Prentice Hall PTR. - Object-Oriented Analysis and Design - G. Booch - Addison Wesley. - UML Toolkit - H. Eriksson and M. Penker - Wiley - JDBC Developer's Resource - Art Taylor - Prentice Hall PTR

3. Java Development Environment The complete Java Development Environment comprises the hardware platform and operating system, the Java Development Toolkit (JDK) libraries and other commercial libraries, the editor and possibly a GUI builder.

3.1 Platforms The main platform for development and deployment of the traditional (X-Motif) software in and around the Prevessin Control Room (PCR) is the Hewlett-Packard HP-UX Workstation. The PC platform with the Windows95 operating system is widely used but mainly for administrative purposes, practically not at all for software development and operation. Despite the fact that every developer had his preferred platform and after an initial trial to develop on multiple platforms, it was clear very soon that the PC was the only viable platform for Java development. Following paragraphs will make this choice evident.

3.2 Java Development Kit The Java Development Kit (JDK) product from [ref 4] contains everything developers need to start programming in the Java Programming Language, and is free of charge. However, since Java is evolving very fast, the JDK release versions are incrementing rapidly as well. At the beginning of 1998, JDK 1.1 was considered as a more or less stable production release. At the end of 1998, JDK 1.2 is the new production release and "Swing" libraries (see 2.6) are getting into the picture. Moreover, all hardware platforms do not have the latest release, nor have the same support. This matter of fact led us to a situation where JDK 1.1.6 was available on Windows95/NT while only JDK 1.1.3 was available on HP-UX. Given this release difference, it is needless to say that a Java application does not behave the same way on those two platforms. At the start of the Java development in the Java-GUILS project in April 1998, it was a sensible but conservative decision to restrict to JDK 1.1 classes. Eight months later, we are practically obliged to "upgrade" to Swing classes for reasons of performance and extra features. 3.3 Editor The choice of an appropriate editor is really up to the developer. For the Java-GUILS project no GUI- builder was used (see 2.7) because of the simplicity of the user interface to be produced. Java WorkShop [ref 5] was the first editor to be used under the HP-UX environment. It is an integrated environment, with a GUI builder, a debugger and some project control features. Due to the inefficiency of the JVM under HP-UX, and the delay in the delivery of newer JDK versions, development on the HP-UX platform was abandoned. The KAWA editor [ref 6] on the PC platform has been used mainly for Java code editing, but only using the basic functionality. The Emacs editor has a Java plug-in and makes the Java code more readable with colour highlighting. In the Java-GUILS project, the simplicity and the quality of the KAWA editor justified its choice by many developers. Benefits are the easy access to the Java documentation, simple organisation of the project files and built-in debugging facilities.

3.4 Development and Runtime Environment On the development platform one needs to install the complete Java Development Environment (JDE), while on the application server platform one only needs to install the lightweight Java Runtime Environment (JRE). The Java Runtime Environment (JRE) offers a reliable environment for deploying Java applications. It includes the Java Virtual Machine (JVM) and a just-in-time (JIT) compiler on some platforms for better performance. Java programs run on different kinds of systems thanks to the JVM. The JVM is a translator that turns Java byte code instructions into system specific commands. The JVM virtual machine is the cornerstone of the Java technology, responsible for cross-platform delivery. The JRE is a subset of the files included in the JDK. It does not include the compiler, the debugger or related tools. The JRE is the smallest set of executables and files that constitute the standard Java platform.

3.5 Java Classes Commercial Java class libraries can be bought of the shelf from software companies. KL Group Inc. [ref 7] is a leading Canadian company for software development products, from which we have purchased the following Java products: x JClass LiveTable: is a 100% pure Java grid/table for creating advanced tables and forms x JClass Chart: is a 100% pure Java data-aware component that enables developers to create graphs and charts x JClass Field is a 100% pure data-aware JavaBean for providing data input and validation for a range of data types, such as date/time, pick-lists, spin-boxes and text fields with string validation. Of course, these commercial libraries evolve as well, so one must follow the product versions. In general, the cost of these professional software packages is fairly low (roughly 500$ per product) and they are well supported. Other commercial companies like RogueWave Software [ref 8] offer similar products, but further investigations were not pursued. Anyone writing Java applets and graphical applications is going to work with the Abstract Window Toolkit (AWT) which is part of the JDK 1.1. The AWT is composed of a package of classes, supporting the creation of buttons, menus and dialog boxes up to complete graphical user interface (GUI) applications. The Java Foundation Classes (JFC) extend the original Abstract Windowing Toolkit (AWT) by adding a set of graphical user interface class libraries as from JDK 1.2. The "Swing" components of the JFC are written in Java, without any dependence on the platform specific graphics system. The usage of SWING will facilitate a customisable look and feel without relying on the native windowing system, will simplify the deployment of applications and will, hopefully, avoid differences in behaviour. Some trials to mix AWT and JFC components proved to be unsuccessful, mainly due to different event management mechanisms. 3.6 User Interface Building Tools KAWA from Tek-Tools Inc. [ref 6] is an Integrated Development Environment (IDE) for building Java applications and applets on Windows95/NT machines. KAWA is a wrapper on Sun's JDK and therefore 100% compatible with any JDK version. Included in this product is a project manager, an editor, a debugger, a class browser and help facilities. Since May 1998, the company also provides a free GUI builder based on both AWT and JFC. Newsgroups and bug reports can be found on their web site. An on-line Java course can be found there as well. Similar GUI builders are VisualAge from IBM, Symantec's Visual Cafe for Java, Borland's JBuilder, and Sun's Java Studio. The Java-GUILS project was not concerned with massive production of User Interfaces. There was only one User Interface to be produced, composed of tables, buttons, trees and 2D graphs. Therefore, it was decided not to use any of these GUI builders.

4. Object Oriented Analysis and Design Given a specific complex problem, one approach is to first build a model that describes the problem to be solved. This exercise is known as Object Oriented Analysis (OOA). Object Oriented Design (OOD) is the second step that consists in the development of a solution to the problem described during the OOA phase.

4.1 Need for It Good software analysis is essential for reducing the complexity of the problem and for separating the description of the problem from the implementation of the solution. We build models of complex systems because we cannot comprehend any such system in its entirety. As the complexity of systems increases, so does the importance of good analysis and modelling techniques. In the mid-eighties, when we were supposed to write C programs, if the problem was complex, one would (sometimes) not start off programming immediately. A recommended methodology for that kind of software development was "Structured Analysis Structured Design". In many software projects in the 80ies, it was difficult to have this methodology accepted by the higher management since not a single line of code was developed during the first months of a project. Nevertheless, the need for SASD was proved especially where maintenance and co-operative development was concerned. A similar approach must be taken to solve problems using the Object-Oriented technology. One cannot just start writing or building Java code. It must be said that unfortunately, there is not one OO methodology that emerges today but rather a set of ideas and recommendations that have to be adapted for each project. Methodologies like Object Modelling Technique (OMT) introduce lots of OO paradigms and development concepts. Notations like the Unified Modelling Language (UML) provide rich semantic for describing OO systems from both static and dynamic points of view. The problem is that none of them proposes a clear process for handling, step by step, a complete OO project. One has to refer to additional books written by people who turned concepts into real OO project management.

4.2 Unified Modelling Language The Unified Modelling Language (UML) is a language for specifying, visualising, and constructing the artefacts of software systems. The UML represents a collection of "best engineering practices" that have proven successful in the modelling of large and complex systems. When we were trying to define the architecture of the Java-GUILS application, UML static and dynamic diagrams and notations were extensively used. Nevertheless, as stated before, UML is not a methodology, it is rather a semantic built as a "catch all" of existing methodologies like OMT, Booch and Objectory/OOSE. Use Cases, which are conceptual parts of UML, are practical scenarios illustrating the primary functions of the system and describing the interaction between the user and the system. They proved to be extremely beneficial in the Java-GUILS project. 4.3 Modelling Tools There are several tools on the market supporting UML and capable of producing Java source code. However none of them were installed at CERN early 1998. An independent software evaluation company called OVUM made a comparison of a number of these tools [ref 9]. We tried out two of them: Rational Rose from Rational Software Corporation [ref 10] and ObjectTeam from Cayenne Software, Inc. [ref 11] (merger of Cadre Technologies, Inc.). Both tools offer the same support for the UML notations and diagrams. Despite the fact that the complete evaluation of ObjectTeam is not finished yet, it is evident that the two products diverge in aspects like configuration management and concurrent development. ObjectTeam stores OO projects into repositories based on Oracle or Sybase and forces the developers to adopt a given development life cycle for each component of the project. Object Team has the concept of software module versioning and locking mechanisms, which offer full support for concurrent development (several developers working on different versions of a same component). Rational Rose covers all aspects of UML but is rather simple to install and to use. It does not enforce a given development life cycle and does not support concurrent development. Diagrams produced with Rational Rose can be stored in an external repository if needed. For a 1-year project such as Java-GUILS, the restricted functionality of Rational Rose was sufficient. In the developer's opinion, the product is not fully finished for reverse code engineering. However for longer- term projects, the more complete, more complex and more expensive ObjectTeam is worth while looking into.

5. What Protocols for Building Distributed Java Applications? The aim of the CERN Java-GUILS project was to produce a Graphical User Interface to the CERN logging systems based on Oracle. Early in the analysis phase, it was decided to build an architecture that would also offer the possibility to interface with other sources of accelerator data (run-time process data, data files, etc.). One of the key questions in this project was the choice of the communication architecture and protocols to be used to access these "data sources" from the Java-GUILS graphical user interface. How could systems like relational databases, UNIX data files and process data, be interconnected to the Java- GUILS application?

5.1 Communication Architecture If the issue were only to connect the Java-GUILS interface to RDBMS systems, the Java Database Connectivity package (JDBC) would have easily solved the problem. As we wanted to be "open" to sources of data other than RDBMS systems, two possible options were discussed as shown in Fig.1: 7+( &25%$ $3352$&+ 7+( -$9$ ,17(5)$&( $3352$&+

Java Guils Application Java Guils Application

Dynamic Code Loading

CORBA PROTOCOL - IIOP

JAVA Data Source Interface

Data Class Data Data Java Corba I Class II Class III Server C Corba Server RMI RMI JDBC RPC C++ Corba JDBC Server Java RPC C data Process Java ORACLE acquisition Process RDBMS C data C++ data process ORACLE acquisition acquisition RDBMS process process

Fig.1 - Two possible communication architectures x In the CORBA approach, the Java-GUILS program would receive data objects from the different data sources (e.g. Oracle, UNIX process, etc.) through a fixed protocol like the one provided by the Common Object Request Broker Architecture (CORBA). A typical CORBA architecture would then consist of servers (C, C++ or Java) that would publish data information on the network. This would imply the need of specific servers for each data source type. x In the Java interface approach, the idea would be not to define a protocol for data exchange but rather a real "Java Interface". This Java Interface would specify which kind of "methods" the data source providers (Java classes) should implement in order to be invoked from the Java-GUILS interface. At runtime, the Java-GUILS program would then dynamically load these data provider classes and invoke their methods in order to establish data connections and to query for data. The choice of protocols would then not be part of the Java-GUILS product itself but rather part of the data providers. One could then imagine data classes using JDBC if they represent data coming from RDMBS systems and data classes using the Java Remote Method Invocation (RMI) and Remote Procedure Call (RPC) if they represent data coming from runtime Java or C language processes.

The second architecture - the Java interface approach - was decided as it did not impose any kind of architectural constraint. Moreover, this approach makes extensive use of two important features of the Java language: the dynamic code loading and the concept of abstract interfaces.

5.2 Database Access The Java Database Connectivity protocol (JDBC) [ref 12] is the primary API for database access in Java technology. It provides programmers utilising Java technology with a uniform interface to relational databases such as Oracle, and a common base on which higher-level tools and interfaces can be built. The JDBC API is included in the JDK 1.1. For transactional processing, the use of the Oracle propriety language PL/SQL is recommended for reasons of performance and consistency. In the Java-GUILS application the data retrieval was fully implemented in PL/SQL on the Oracle server side. However, the current version of JDBC 1.2 is a standard low-level access method. There is no implementation for optimised data intensive queries. In JDK 1.2, it is planned to include a newer specification for JDBC 2.0, which will finally allow fetching arrays and support the complex data types (objects) from the Oracle8 database. In the non-OO world, a host language such as Pro*C has an "array fetch" implementation to get large amounts of data that minimise the network traffic. SQLJ is Structured Query Language (SQL) embedded in the Java programming language -it can be thought of Pro*Java-. SQLJ offers a simpler and more productive programming API than JDBC to develop applications that access any Relational Database Management System (RDBMS). The Java source is precompiled and the embedded instructions are converted to standard JDBC calls. SQLJ provides a more productive API, but obviously, it does not improve performance in comparison to JDBC. Oracle's SQLJ is currently in Beta phase, but looks promising to the early adopters.

6. General Issues This chapter outlines some good practices that will help your Java development. Most items are very well known but easily forgotten.

6.1 Central Repository and Support All data related to the project development should be stored in one central repository, accessible by the complete development team and (partially) readable by the outside world. This concerns not only the code, but as well software tools, beta libraries and documentation. Concerning the software tools, the ideal situation would be to have them centrally available and maintained at CERN. In practice however, most Java components are just emerging new tools, with few people using them at CERN having hardly any experience. At the beginning of 1998, the Java-GUILS project suffered from the absence of centrally managed tools and a large amount of time and effort was spent on finding, evaluating and installing all necessary development tools.

6.2 Communication The Java technology is an exponentially growing environment in today's information technology (IT) world. The number of Java components (Java applets and JavaBeans), tools for Java (Java builders) and Java-enabled tools (browsers, etc.) is increasing every day. The AltaVista search engine [ref 13] found over 5 million hits for Java, and these do not concern coffee. The real problem is getting to the right piece of information, the Java classes that fit your application. On a Java project, developers must spend some time to follow up these new possibilities. Also, subscribing to Java newsgroups can turn out very effective.

6.3 Documentation There is a documentation tool included in the standard JDK called "". This tool parses the source files, searching for special format comments, and constructs HTML files showing the classes, variables and methods definition and hierarchy. We see three advantages of Javadoc: x it offers a de facto standard for documenting Java source code x as an automatic process, it keeps the documentation in synchronisation with the source code x it generates documentation in the HTML format 7. Java Critical Issues The issues addressed in this section are major topics of concern for people envisaging to deploy operational systems based on the Java technology. As we will see, the choice of Java as a development and runtime platform may have some serious consequences on present working habits. Java as an emerging technology may also require frequent upgrades of the software and considerable amounts of memory and CPU resources.

7.1 Java Availability One of the major observations is that the best platform for Java development is Windows 95/NT. This may sound as a contradiction regarding the traditional opposition between the Microsoft and the Java communities [ref 14], but it is an undeniable reality. The most recent JDK version, most of the development tools and commercial Java beans are first (and sometimes only) available for the Windows95/NT platform. During the Java-GUILS project, the Windows95 JDK 1.1.6 was used while we still were blocked with a JDK 1.1.3 on HP-UX. Most editors like KAWA and modelling tools like Rational Rose for Java are only available for the Windows95/NT platform. At the beginning of the project, we deliberately decided not to impose any particular development environment to the developers. Some of the developers started on the Windows95 platform while others decided to go the HP-UX way. Three months were sufficient to convince the HP-UX developers to move to the Microsoft development environment. Continued development on the HP-UX platform would have resulted in spending a significant amount of time just "to get it working" at all levels. In November 1998, toward the end of the Java-GUILS project, we finally received the JDK 1.1.6 for HP-UX, the first release offering stability and acceptable performance.

7.2 Java Performance The improvement of the Java performance is and will be a key factor for the future. One can not deny that for the Java-GUILS category of applications, it is not possible today to reach the same level of performance as we have with X/Motif as graphics platform and Pro*C as RDBMS access methods. Regarding the graphics aspects, it is not very surprising as the Java Abstract Window Toolkit (AWT) is implemented on top of the platform native graphics system (X/Motif for UNIX and Windows for Windows95/NT). Regarding the performance of the RDBMS access, the present JDBC technology works well but can't provide the same level of performance for the transfer of large data sets as the Pro*C implementation. At this point in time in the Java-GUILS project, some efforts are still concentrated on the improvement of the performance. The following table illustrates the performance tests done in November 1998, by executing typical queries on SPS and LEP runtime data.

Configuration Start-up time LEP query SPS query Java-GUILS on Windows95 166MHz 32Mbyte RAM 60 sec 20 sec 40 sec JVM 4Mbyte Java-GUILS on Windows95 200MHz 32Mbyte RAM 30 sec 23 sec 40 sec JVM 8Mbyte Java-GUILS on HP-UX 100 Mbit network 37 sec 16 sec 30 sec JVM 8Mbyte Java-GUILS on Linux 260 MHz 22 sec 20 sec 36 sec JVM 8Mbyte Pro*C-GUILS on HP-UX 100 Mbit network 20 sec 8 sec 9 sec optimised Pro*C array fetches Surely, performance is directly linked to the CPU architecture and processor clock speed, to the available system memory and to the usage of the system resources by other users or processes. The performance figures above were measured on the different platforms Windows95, HP-UX and Linux, but no real comparative conclusion can be given due to the intrinsic differences between the machines on which the tests were performed (single CPU versus multiple CPU, stand-alone PC versus HP-UX server, etc.). However, it is clear that Java technology is today resource consumptive and one needs to anticipate this reality in the early phase of a software project. Also, a fair amount of time must be spent on optimising and tuning in order to get a better performance.

7.3 Java Portability Portability is the great promise of Java technology. In our opinion, cross-platform portability is an important factor, especially for future projects in the CERN accelerator domain. Portability gives us an extra degree of freedom: the choice of platform is not imposed while developing the software. We experienced several behavioural differences between the different platforms (e.g. different mappings of the components on the screen, slightly different behaviour of mouse events). As we received more recent versions of the JDK for UNIX, these differences tend to reduce and it is fair to state that Java holds its promise: Java byte code runs on different platforms provided that the same JVM version is installed. This is very encouraging as it offers us a large range of potential platforms for deploying 100% pure Java applications.

8. Pros and Cons of Java As any software tool or language, there are benefits and drawbacks when making use of it. This chapter enumerates the major pros and cons of the Java language, compared to the traditional C procedural language that we are used to in the accelerator control environment, and compared to its OO follow-up C++.

8.1 The Advantages of the Java Language Java has proved to be a very powerful and user-friendly language to work with. We summarise here some of these advantages we have made use of during the project: x Java is truly OO. Everything in Java is an object, except for basic data types like "int", "double", "long", "char" and "boolean". There also exist the corresponding objects for these basic data types. x Interfaces & Single inheritance. Java does not allow the possibility of having multiple inheritance in a class as in C++. Multiple inheritance may cause major problems in C++ (crashes of methods and variables names, possible to inherit from the same class more than once). Java offers a better solution than C++, by the use of interfaces. Interfaces are treated like true object types. They provide the definition of the methods that have to be implemented by the class. x UML to Java. The syntax used in UML for modelling has a very straightforward mapping to Java. Concepts like packages, inheritance, interfaces, relations… have their direct mapping in Java. x Dynamic code loading. This feature consists in the ability of loading a class at run-time. This fact is useful for hiding implementations of interfaces, and also to customise the classes that participate in the execution of a program (concept of plug-ins). x mechanism. The Java language has a very powerful, built in, exception handling mechanism, which takes care of the systematic treatment of errors. x Reflection mechanism. It is possible to grab an object in JAVA and ask for its type, variables, methods and constructors, and subsequently create another instance of this type or call any of its methods. x Object serialisation. One can create a persistent object by serialising it to a file. Later, this object can be recovered, and it will appear with the same state as it was before being serialised. This feature can be used, for instance to save program configurations. In other languages, this feature must be provided by use of Object Databases. x Network Oriented. Java has an extensive library of routines for dealing with TCP/IP protocols like HTTP and FTP. Java applications can open and access objects across the Net via URLs with the same ease as when accessing a local file system. x Easy Multi-threading. The Java language directly supports the creation of threads. Opening a new is simple, and very well supported by the Thread class. The code written for this matter is portable, but the behaviour under different platforms may probably vary depending on the capability/ability of the host system to support multi-threaded processes. In Java-GUILS, the data acquisition from the data sources is done using background threads. So there is a thread per data object being actively queried.

8.2 The Drawbacks of the Java Language The human nature that tends to resist to changes is applicable to the software engineer as well. However, resistance to change is not a good reason enough not to make the step to Java technology. With the experience we gained, these are the objective drawbacks of the Java language: x Java development can only take place on the Windows95/NT platform since practically no Java modelling tools or high-level development environments (i.e. User Interface Management Systems) are available in the UNIX environment. This situation might change in the future, but is a fact today. x The training investment in OO methodology should not be underestimated, especially for software engineers with a traditional procedural modelling and programming background. Conceiving abstract classes requires a mental leap and a cultural change. However, the new generation of IT people graduating from university, may have overcome this barrier. x Currently, in terms of speed performance, Java is still behind the mature and optimised C programming language. C programmers do not have to worry about performance and do not have to spend time on searching for tuning tricks. The contrary is true for Java. x The Java platform and its associated commercial products are evolving rapidly. New versions of JDK are generally more efficient but always introduce a slightly different behaviour, which has an impact on other parts of the development. To keep in step with the technology requires a fairly intensive maintenance of the developed software. x The distribution of the JVM releases as well as the level of support for the JDK libraries varies significantly according to the operating system vendors. This is an important issue if cross-platform deployment is required. Each of the above drawbacks can evolve in the near future. In fact, we are convinced that they will evolve positively in the next two years, due to the willingness of a large part of the IT industry to make Java happen.

9. Conclusions and Recommendations For the careful reader of this document, it is already clear that it is impossible to give a straightforward conclusion on the choice of Java for a large software project in the CERN accelerator domain. However, following observations are the main points that can be emphasised. The Java-GUILS project allowed us to prove the feasibility to create a pure Java operational tool. Starting almost from scratch, it took 2 man-years to choose, install and learn the development environment and address successfully problems like database access and graphics. Therefore, we are convinced that the Java technology is mature enough and ready to be deployed. However, caution needs to be taken with respect to performance issues. Despite the efforts of experienced Java programmers, the overall performance is still lower than the objectives and what we are used to in our accelerator control environment. A non-negligible part of development time must be spent on performance tuning. For developers originating from the traditional procedural programming world, a distinct investment of training is needed to overcome this cultural change to Object Orientation. The fast evolution of the Java technology has its benefits and its drawbacks. New possibilities can be implemented continuously, but maintenance is not an easy task. Nevertheless, it is recommended to stay in step with the evolution of the technology. The on-line access and control of accelerator equipment has not been looked into during the Java-GUILS project. The Java-API project [ref 15] will address this issue in the framework of the PS/SL controls convergence project.

References [ref 1] Java Graphical User Interface for Logging Systems, Simplified Architectural Design document - R. Billen, E. Lorente, G. Smith, M. Vanden Eynden - CERN SL/99-02 (OP) [ref 2] Real Time Structured Analysis and Structured Design for Embedded Systems, A. Kennedy - tutorial at CERN, February 1988 [ref 3] CERN Technical Training, Software and Systems Technologies - http://www.cern.ch/Training/ENSTEC/P9798/Software/content.htm [ref 4] Sun Microsystems Java products - http://www.sun.com/java/products/ [ref 5] HP-UX Edition of Java WorkShop by Sun - http://www.hp.com/esy/go/softbench.html [ref 6] KAWA from Tec-Tools, Inc. - http://www.tek-tools.com/kawa/ [ref 7] KL Group - http://www.klg.com/ [ref 8] RogueWave Software - http://www.RogueWave.com/ [ref 9] Report on UML tools from OVUM - http://www.ovum.com/ [ref 10] Rational Rose from Rational Software Corporation - http://www.rational.com/rose/ [ref 11] ObjectTeam from Cayenne Software, Inc. (web site under construction) see [ref 9] for detailed report [ref 12] Oracle JDBC drivers - http://www.oracle.com/st/products/jdbc/ [ref 13] AltaVista search engine - http://www.altavista.com/ [ref 14] The Halloween Documents - http://www.opensource.org/halloween.html [ref 15] The CERN PS/SL Java API project - http://hpslweb.cern.ch/pssl/