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.
|
