BABAR JAVA POLICY
17 April 1998
- ATTENTION: if you are involved with Java coding in BaBar, please subscribe to the Java Usage HyperNews Form. More information on Java in BaBar and SLAC can be found
there.
HISTORY
Many BABAR developers have expressed a need for writing applications that involve remote interprocess communication and/or graphical user interfaces. A lot of interest has arisen in the online and database groups in both CORBA and Java as solutions for
this need. Several collaborators have already started projects involving both of these technologies. Many others have Java in their future plans.
POLICY
This policy was commissioned to recognize two opposing desires: to sanction the use of Java, a new programming language; and, the need to ensure the successful completion of the BABAR code development by assessing the risk and, possibly, restricting the
use of new technologies. After consideration of both elements, the policy is, effective immediately, to permit the use of Java within BABAR subject to the guidelines put forth below. This policy should be reviewed at some future time to determine whether
the restrictive elements contained within the guidelines should be relaxed.
GUIDELINES
Each the guidelines listed below is justified and discussed in more detail at the bottom of this page.
- Java programs should be written for version 1.1
- Platforms should install a JDK closest to Sun's 1.1.5
- No deprecated features from 1.0 should used
- Platforms must have Swing 1.0.1 installed
- Use of the JFC through Swing is encouraged
- The use of other Java packages not part of the JDK will need to be approved by the computing management
- Classes should be written under the "hep.babar" package.
- Classes will be compiled for each platform individually
- Classes should be properly commented for useful javadoc document generation.
- Java development should be for writing thin client applications only. In particular, Java applications should not be in the processing chain for event data.
- Where a high level interprocess communciation protocol is desired between the Java client and its server, use of CORBA is strongly encouraged and use of RMI is forbidden. Low level communication using sockets is allowed.
- Only the approved Java ORB should be used for CORBA development in Java classes
- The use of the Objectivity for Java product is restricted. Java applications may not be written to perform write accesses to the BaBar Objectivity databases. Read access may be acceptable if further investigation shows that it can be granted at the
session or transaction level in a way which prevents application code from promoting it to write access. In general, for any BaBar database, Objectivity or not, which is provided with a data protection wrapper for use in C++, direct Java access to the
database is prohibited.
- More detailed BaBar coding standards for Java will be developed and promulgated by consultation between offline and online experts.
- The functionality provided by Java applications should not be required or integral to running of the BABAR offline software
- Before starting a new Java based project in a BABAR package, the BABAR computing management needs to be notified and approval granted.
ADDENDUM
- Use of the stop, suspend, and resume methods for the Thread class and its descendents is strongly discouraged in anticipation of their deprecation in JDK 1.2. (Added May 8, 1998)
Guideline Details
Java is still a rapidly evolving technology. It is also currently undergoing a beta period for a major upgrade from v1.1 to v1.2. Even though Java advertises itself as "write once, run anywhere", its actual architecture independence is only as good as the
Java virtual machine (JVM) implementations for each platform. Currently this situation is not ideal. Since Java is "owned" by Sun, support for the latest versions of the JVM continually lag behind for our other BABAR supported architectures. Therefore
universal availability of v1.2 is probably a long way off. This leads to our first Java guideline:
- (1) Java programs should be written for version 1.1
Within version 1.1, there are sub releases. Both Solaris and Digital UNIX have official 1.1.5 releases of the Java Development Kit (JDK). HPUX has a 1.1.3 release. AIX has a 1.1.2 release with a 1.1.4 in Beta. It would too restrictive to require every
platform to pander to the lowest common denominator (1.1.2 on AIX). We need more experience before we can access the problems of having different sub releases on different platforms. So for now,
- (2) Platforms should install a JDK closest to Sun's 1.1.5
It is therefore suggested to use the 1.1.4 beta for AIX. Sun claims that Swing (see below) is buggy on pre-1.1.5 releases. Also, using the Java Bean Development Kit (BDK) requires 1.1.4 or better. There may be some features developers want to use that are
only available in the latest 1.1.5 release. Instead of pandering to the lowest available version, use of these features is not forbidden but please consider alternatives if reasonable.
The JDK 1.1 still supports several features of the 1.0 version that are now labeled as deprecated. The largest example of this is the 1.0 event model for Abstract Windowing Toolkit (AWT). These features will probably not be supported in some future
version. Therefore
- (3) No deprecated features from 1.0 should used
One of the major new features coming to 1.2 is the Java Foundation Classes (JFC). This adds several new, useful GUI elements that extend, and in some cases replace, elements of the AWT. A Java archive (JAR) called Swing exits for use with the JDK 1.1 that
gives access to many of these features now. Use of the JFC through Swing should make an eventual upgrade to main GUI paradigm of v1.2 more painless. Therefore,
- (4) Platforms must have Swing 1.0.1 installed
- (5) Use of the JFC through Swing is encouraged
- (6) The use of other Java packages not part of the JDK will need to be approved by the computing management
The main reason for point (6) is to discourage the proliferation of 3rd party JAR files scattered throughout the BABAR package directories. We wish to centralize the location for these files and this will require coordination. Note that Java Bean support
is part of the JDK. A developer is free to use whatever "beanbox" tool or other Java development tool is at their disposal as long as no part of the tool is required to actually compile and use the generated classes and the code that is generated follows
the other guidelines outlined here.
Sun strongly encourages the use of packages for maintaining a clean namespace. Package names have a syntax that similar to Internet domain names (e.g java.awt.event). As a common practice, Sun suggests companies write their classes in a package that is
the reverse of their major domain name (e.g. com.microsoft.office). This pattern is not ideal for our widely scattered collaboration. Instead, we suggest the following:
- (7) Classes should be written under the "hep.babar" package.
The full package name used will relate to the BABAR package name. For instance, java classes that are part of the BdbTools should be written to be in the package "hep.babar.BdbTools". Writing classes in a package requires that the class files be present
in a subdirectory hierarchy that corresponds to the package name, therefore, the above example would require the Java class files be present in a subdirectory hep/babar/BdbTools underneath the BdbTools package directory. This makes things a bit clunky.
Instead, each package containing java code should put in a java subdirectory in the package. At the top level release directory will be the subdirectory java/hep/babar. From there will be a symlink to the java subdirectory of each package containing java
files. For example:
6.4.1/java/hep/babar/BdbTools -> ../../../../BdbTools/java
One can then run the java compiler from the 6.4.1/java directory on the desired java source files.
One of Java's selling points is that java classes compiled on one platform can be run on all other Java supported platforms. As discussed earlier, this ideal is not quite yet reality. Therefore, for now,
- (8) Classes will be compiled for each platform individually
For the example above, this means that each lib/$BFARCH directory will have its own copy of the BdbTools.jar file. This should make it easier to work Java support into SRT.
Java has a well developed mechanism for documenting classes using specially formed comments within the source file called javadoc.
- (9) Classes should be properly commented for useful javadoc document generation.
Known plans for Java in BABAR software are for writing thin client GUI applications that will communicate with a server for data display and control purposes. What method the client and server will use for communication will have effects beyond the domain
of one package and therefore a standardization is necessary. Java has a builtin package for interprocess communication called Remote Method Invocation (RMI). However, this will only work if both server and client are written in Java. Therefore,
- (10) Java development should be for writing thin client applications only. In particular, Java applications should not be in the processing chain for event data.
- (11) Where a high level interprocess communciation protocol is desired between the Java client and its server, use of CORBA is strongly encouraged and use of RMI is forbidden. Low level communication using sockets is allowed.
It is not yet clear if (11) is currently feasible and a study is currently underway to study this issue. CORBA itself is still a rapidly evolving standard for remote interprocess communication. Several commercial and freeware tools exist for CORBA
development for both Java and C++. The current leading candidate in online for a C++ tool is the TAO package. CORBA tools for Java are in an even less developed state. We are investigating if is possible to get Java clients and C++ servers to communicate
using CORBA with the currently available tools. It is expected that the a result of this study will be a choice of a specific Java ORB. This should become a standard for BABAR and therefore leads to
- (12) Only the approved Java ORB should be used for CORBA development in Java classes
The integrity of the BaBar databases, especially but not exclusively the Objectivity federated database, is protected in most existing applications by providing users access to data through transient interface classes in C++. This allows the creation of a
fence around the database which prevents the storage of semantically invalid data. This pattern should be extended to cover the thin client/Java world, which will be interacting with the configuration and conditions databases, though not, to be sure, the
event database (see item 10 above). So that the data protection layer need be written only once and can be used from any BaBar application, it is necessary that it be provided in C++. Hence,
- (13) The use of the Objectivity for Java product is restricted. Java applications may not be written to perform write accesses to the BaBar Objectivity databases. Read access may be acceptable if further investigation shows that it can be granted at
the session or transaction level in a way which prevents application code from promoting it to write access. In general, for any BaBar database, Objectivity or not, which is provided with a data protection wrapper for use in C++, direct Java access to the
database is prohibited.
This rule may be waived at the discretion of computing management in individual cases. The exception is meant to cover certain high-level database management applications that have been envisioned.
Experience within BaBar has shown the value of our established coding standards for C++. With Java, we enter an entirely new domain in which developers could go down widely divergent paths in the absence of collective guidance, so:
- (14) More detailed BaBar coding standards for Java will be developed and promulgated by consultation between offline and online experts.
These standards will most likely share a lot in common with the C++ standards for the more general OOP issues.
Finally, since it is a new technology, the use of Java in BABAR should proceed with caution. The next several months should be considered a trial period while Java and its affects are evaluated. It is therefore necessary to put the following
restrictions on Java use during this trial period:
- (15) The functionality provided by Java applications should not be required or integral to running of the BABAR offline software
- (16) Before starting a new Java based project in a BABAR package, the BABAR computing management needs to be notified and approval granted.
ADDENDUM details
The stop, suspend, and resume methods for the Thread class will be deprecated in JDK 1.2. The reasons for this are described in a Java Report article by Scott Oaks. The
main point is that these methods do not (and never have) work well within Java's model of object synchronization. Therefore:
- (1) Use of stop, suspend, and resume methods for the Thread class and its descendents is strongly discouraged in anticipation of their deprecation in JDK 1.2.
It is best to code for this change now as making the change later will be very painful.
Contact
Paul Raines will serve as the main contact point for Java use in BABAR. Please contact Paul with questions and requests. |
