HP-UX Java™ – HPjconfig: A Case Study of Java Cross-Platform Development

Configuration advice for the HP-UX kernel and the Java™ Virtual Machine (JVM) is needed to deploy Java™ applications for the enterprise. HPjconfig provides initial setup information. It also offers specific settings tailored to the requirements of your deployed application (Web Server, WAP server, Application Server, etc.).

This paper describes the development process used by an HP engineering team to create the HPjconfig product. The project team utilized various software tools and methods, as they became necessary at each point in time. This allowed the project to proceed quickly, since additional process steps were added only as necessary during development. Since the development process was only as heavy as necessary, milestones were reached faster and therefore with minimal frustration on the part of the HPjconfig engineering team. As each milestone was reached, or as team members were added to the project, the development process was tuned.

The following is a summary of the software development practices used by the HPjconfig project:

As HPjconfig team members were added and the project approached release, additional tools were added to the project. Additionally, some tools were "swapped out" for more robust counterparts as needed. For example, we used Microsoft's Visual SourceSafe (VSS) when the project team expanded beyond the initial size of two software engineers. All of the project engineers could therefore easily access the HPjconfig sources and associated documentation (release notes, test scripts, etc.) In addition, as new features were implemented, the project engineers could checkout the files (with multiple simultaneous checkouts allowed) and then merge back in the changes only when they were checked back into VSS.

The editor of choice for each engineer had to have tab settings, indentation style, etc. that could be set to agreed upon settings. This provided an overall consistency to the source code so the project development could proceed at the maximum possible speed, while minimally impacting each engineer's programming creativity and therefore productivity.

When the HP AppDev Java™ team recommended a tool, we asked a team member to use the tool and therefore evaluate its effectiveness in an actual Java™ software development project. Our philosophy is: "the tools we ask others to use, we will also use."

The coexisting RAD philosophy of keeping the software development process "thin" resulted in the addition of new tools only as they became necessary for either the project lifecycle (i.e. the Alpha release of HPjconfig) or the addition of new software developers to the HPjconfig project. This "use a tool as it becomes necessary" philosophy became the order of the day and allowed us to follow the best practice of requiring only the smallest amount of overhead as was necessary to get the program built.

HPjconfig was developed using an object oriented development methodology. Initially we used hand drawn GUI design diagrams to show a 'mockup' of the system. These provided a user-centric view of the utility, and were developed using an iterative lifecycle to add/remove features from the GUI model.

Once we had chosen a "deck of cards" Swing GUI paradigm it was simply a matter of adding the various GUI components to the card deck. The GUI component used in HPjconfig to perform the actual kernel parameter calculation is a spreadsheet with specific meanings assigned to the columns, for example kernel parameter name, etc.

In addition, there are many simplistic coding examples available on the internet. Some of the examples can be modified and expanded into a full-featured GUI requiring less effort. These examples give you the ability to develop a GUI piece by piece without having to build the GUI from scratch. You can select each Swing GUI component and drop them into the expanding GUI framework that you are building.

Once we had decided on the GUI framework it was relatively straightforward to add additional capability via additional sets of buttons or by adding panels to the HPjconfig GUI "deck."

As each major feature (the superuser mode, SAM integration, HTML Help, etc.) was added to the project, it was first designed by the architect and then discussed by the project team members before finalizing the design.

Each new feature was added incrementally, and was developed, unit tested, and finally regression tested. We used the combined abilities of the HPjconfig team to test each other's (and their own) code. Each engineer stress tested the new features and tried to get them to fail. In addition, because of the teamwork and espirt de corps of the HPjconfig team members, a "peek" into the implementation by the coding engineer was given. Many times this took the form of "...try to break this [min or max] limit of the code; a special case or end condition check is employed at times..."

Only after the usual regression testing suite passed and the "HPjconfig team-based stress testing" passed muster, was the code deemed of acceptable quality to become an official candidate for release (i.e. either alpha, beta, or final).

The software development process we used can be summarized as follows: every tool we used either added value by reducing the overall wall-clock development time, or by automating some otherwise tedious process such as checking the source code semantics over and above what the Java™ compiler (javac) automatically provides.

We used Java™ based IDEs because we wanted to see if they could "play" in one another's development space without requiring source code modifications. Since the E/C/D cycle was short, sometimes minutes, in a few cases just seconds, each developer could try an incremental change prior to committing it to the project sources.

Each developer used their own personal "sandbox" area; so that changes could be tried on, tested and then checked back in. Initially, the "card deck" GUI was prototyped by one developer, and the XML/DTD database and "spread-sheet" panel by another developer. This allowed development of the software in parallel and provided an environment where daily or weekly "high-fives" sessions were regular occurrences as each development milestone was attained. In addition, because each engineer was responsible for their own portion of the GUI, everyone had multiple accomplishments that were both visible and provided suitable moments for celebration.

As the initial GUI prototype was first developed, each feature could be easily integrated and unit tested from within the GUI framework. We obtained early feedback on GUI architecture and design by showing the project manager or some other reviewer the working GUI component, soliciting their feedback, and then describing the next feature we were going to implement. In this manner, the tool took shape in front of the most important team member's eyes, the project manager.

Tip
As all IDEs are not equal, you should be sure the one you select provides the following properties, as defined by your project:

An easy E/C/D cycle for your project coding needs/requirements.
Works in conjunction with the JVMs you are developing for.
A usable debugger, so that most of the project debugging from the individual's perspective takes place within the IDE or is enabled via the IDE.
A mechanism to allow or completely support the projects coding guidelines (e.g. indentation style, tabs vs spaces, etc.)
[Your project specific IDE needs/requirements go here...]

Initially, each of the engineers used their own source management control as the project was easily partitioned into two distinct parts. As the team grew beyond two to three software engineers, a more rigorous approach was required. The PVCS® database was converted to a Visual SourceSafe (VSS) one, and the various clients (i.e. NT, W2000, W98) were loaded to access the VSS database as needed. This proved to be an easy, simple way of keeping track of the project sources, HTML help files, etc. without the expensive overhead of additional process restrictions, procedures, rules, or training. We found VSS easy to use for our limited purposes, and the addition of the visual file difference utility made the infrequent source code merging easier than originally expected.

Tip
SCM systems are only as good as the processes that engineers understand and use them with. Be wary of process-heavy tools that provide many features at the expense of overall simplicity of use. Whenever possible, utilize a SCM solution that is integrated with your IDE.

We edited the HPjconfig source code exclusively on the NT platform, utilizing the editor chosen by each developer. Agreement on indentation and coding styles helped to keep the expanding source code base readable and more supportable for each software developer as they came on the project.

Tip
Use the editor of your choice, not the "chosen" editor. Editors are a personal preference. You should not attempt to convert software engineers from one editor to another. Instead, the indentation and code style guides should be followed to provide a consistent "look" to the source code.

All initial compilations took place on the NT platform - utilizing JavaSoft's SDK and its affiliated APIs. This process assured that all source code that was created was Pure Java™, and would therefore inter-operate with the greatest ease on all platforms (HP-UX, NT, etc.) throughout product development. Additionally, we compiled for acceptance testing on the HP-UX SDK. We tested on pre-releases of the HP-UX SDK and any issues with the upcoming release (as far as HPjconfig was concerned) were resolved prior to the final release.

Tip
Develop the Java™ software to be platform neutral, and then make it work on a particular deployment platform. This way, the developer spends the least amount of time wrestling with platform specific issues. (Recall that HPjconfig is currently an HP-UX speciftool setity.)

In addition, building the software from the ground up to be multi-platform regardless of the initial target platform allows the developer to choose development tools based on its capabilities. This is preferable to being limited to platform specific choices and the limitations of that platform's toolset and pricing structure.

Since we used a cross-platform software development model from the start for HPjconfig, issues surrounding the HPjconfig application requirement and this model had to be resolved up front. The E/C/D cycle on the NT side had to be automatic and all encompassing; or at least enough to provide each developer with a ~95% debugging solution, that is debugging prior to acceptance testing. After all of the issues with the existing code were debugged, the Java™ source files were then recompiled and re-tested on the HP-UX platform. In this manner, any remaining HP-UX specific problems could be tested on various SDKs on HP-UX systems.

Always requiring that the software be runnable on NT or HP-UX (with a "snapshot" of the various system call output) facilitated easy testing of new features, and provided immediate feedback to the developer as to whether the changes just made broke something else in the system. Because of the dramatic increase in the E/C/D cycle, each new feature could be incrementally "tried on for size" and various issues and defects could usually be dealt with up front as they were being developed. In addition, this quick turnaround E/C/D cycle facilitated relatively quick feature development and unit test cycles, providing each engineer with almost immediate feedback concerning his or her success (or sometimes lack thereof) of adding another feature to HPjconfig.

We used TogetherSoft's ControlCenter automated source code review recommendations. Additional feedback from HPjmeter output were utilized to help enhance the performance of HPjconfig.

Tip
It's important to first design and build Java™ software that is both maintainable and supportable. Performance tuning can come later in the software development lifecycle. There is always time to tune; once your program works correctly, that is!

From a technical standpoint acceptance and regression testing is the final release hurdle. This must be performed on the release platform (HP-UX in the case of HPjconfig) and with the specific version of HP-UX, SDK, and hardware platforms that HPjconfig is expected to run on in the field.

Cross-platform Java™ development allows you to check the operation of the program on another platform to see if the same problem occurs on both platforms. This way, you can more easily identify SDK and platform specific problems. Also, the pricing structure of the tools and the best of class features of a specific tool can be chosen with less regard for a single platform's tool-set.

By providing you with a larger number of tools, cross-platform development can help expedite the software development process. At the same time, additional source code quality checks (via tools and a shorter E/C/D cycle) and lower tooling costs are possible.

Data Type Declaration (DTD): Defines a set of definitions when applied to a XML document define the set of valid elements that may comprise the XML document.

Edit/Compile/Debug (E/C/D): The standard incremental development mini-cycle of editing a source file, recompiling it, and then checking the resulting code by an incremental feature check.

Integrated Development Environment (IDE): An integrated editing, compilation and debugging environment for Java™ and/or other languages.

Java™ Virtual Machine (JVM): The program that reads the class file format and correctly performs the operations specified therein.

PVCS®: Project Version Control System or Profession Version Control System family of Enterprise Change Management products.

Rapid Application Development (RAD): The software engineering methodology of writing a GUI framework first, so that team members and others can get a quick "look and feel" for the product prior to the implementation of the complete functionality of the product.

System Administration Manager (SAM): HP-UX system administration software for configuring the kernel parameters, network settings, etc.

SDK: Software Development Kit (exclusively for Java™ within this document).

HP-UX Java™ – HPjconfig: A Case Study of Java™ Cross-Platform Development

HP-UX Java™ – HPjconfig:
A Case Study of Java™ Cross-Platform Development