Before any coding begins, you must know the answers to two questions:

The answers to these questions affect all Java-related product choices and development methodology decisions.

The project objectives are derived through a business diagnosis study, which concludes with a recommendation that one or more business processes can be improved. This task is typically conducted with business analysts who understand the value proposition of the business domain under investigation.

Once it is determined that a business process can be improved, a project team is formed to begin to assess what kind of business process re-engineering effort is required: social, technical, or a combination of the two. This effort is typically referred to as the Project Inception phase, where the objectives (mission) and feasibility of the project are reconciled. It is imperative for the project objectives to be declared in a clear and concise manner to avoid any misinterpretations by the recipient community who will be giving the green light to go ahead with the project.

If the project is feasible, one of the deliverables of the Project Inception phase should be an initial draft of a project plan that explains at a very high level the tasks required to implement the objectives, as well as a ballpark timeline as to when the respective tasks and overall project will be completed.

The actual timeline of the project is affected by two factors:

In essence the software methodology should be qualified by the business delivery requirements, and hence must be considered and selected before development starts. It is extremely valuable to follow an application development methodology from the beginning of a project because it is much more difficult to adopt a new methodology in the middle of a project. Only the new parts of the project will be following the methodology, whereas the other parts are under a different methodology, or are simply the result of ad hoc programming without any methodology.

Many factors come into play when choosing software products for a project. Primary among these factors is your company’s existing environment and standards, and hence you may not have a choice in the product you use. Some of the other major factors include the following:

When researching a product, ask colleagues for personal recommendations and join newsgroups to gather other opinions regarding a product. Find out, from the vendor or your other sources, about successful implementations where a product was used. If you still have questions about a product that is critical to your project, establish a working relationship with a training company specializing in the product. The trainers generally know the technology and can provide insights into its proper usage that you would obtain only through trial and error.

Initially, it is good practice to list the types of products you will be considering within your Java development effort:

After you have identified the products that will potentially be used in your development effort, gather the following information for each product:

This information will enable you to make intelligent choices about which versions of the products to use. In most cases, an evaluation copy of the product can be downloaded. You should contact the sales account managers from the product company to bring in the systems engineers to present or demonstrate the prospective products and show how the vendor’s products all work together. You should be able to identify any compatibility issues, either now or in the near future, that could affect your delivery date. More importantly, you should be able to determine whether a vendor’s planned release date, with a potential schedule slip, has an impact on your own critical path.

Choosing a software build and source control system are two very important decisions when starting a project. Many projects have these options determined by corporate standards. If you do not already have a source code control system and a software build process, do not underestimate the work involved in getting them in place and do not underestimate the negative impact on your project if you do a poor job.

That said, allocate enough resources to create an easy-to-follow system for building and maintaining your source code. Your source code control system should work hand-in-hand with the procedures for performing system builds. When you have a working system, make sure to create instructions on how to set up and use the system. Provide cookbook instructions covering the day-to-day operations for developers. Also, create a dummy area in your source control system where developers trying to learn the system can practice without doing real damage.

The idea is to simplify compiling and testing as much as possible for the developers. This issue is directly addressed by Integrated Development Environments (IDEs) for Java. For example, the Together ControlCenter design tool includes built-in support for building and packaging the application for a particular platform. If the command-line compiler is being used from the Java SDK, scripts or make files should be developed to ensure that the environment being used for the build is under version control. The development environment and version control systems are discussed later in this chapter.

If you end up requiring the developers to use the make utility, provide build templates and a working demo. Be sure you cover other than the most trivial cases, as make’s error messages (or lack there of) are notoriously cryptic. A trivial application is one that contains all of its source code in a single directory. Enterprise applications are not trivial. Hence, the make file template must provide access to all the tools and libraries required by the developer.

The first step in software development, after at least an initial high-level detailed design, should be the creation of an environment for programming, compiling, testing, and running your applications. An environment at the most basic level consists of directories, control parameters (commonly called environmental variables), and programs. The programs are the software products you have chosen. These are usually installed in their own directory structures, with their own sets of environment variables. It is your task to create a development and runtime environment around these products.

The directory structure should accommodate both the system and the individual developer’s needs. The directories of the individual developers should mirror those of the project wherever possible. The importance of normalizing the directory structures is twofold:

Most source control systems will enable the developer to set his own working directory on his machine, and this can vary from one developer’s machine to another. However, the directory structure under that working directory for a specific project should be mirrored against the structure in the source control system.

Figure 4.1 shows a developer’s configuration containing most of the necessary directories.

Figure 4.1. The Java developer benefits from a logical and structured directory layout.

You should note the following points about Figure 4.1:

It is important to become familiar with the development environment and the respective environment variables that can be used to customize your environment. The most important environment variables are PATH and CLASSPATH:

It is important that these variables do not contain references to obsolete or improper versions of the software. The following list provides instructions to identify the Java development environment on a Windows system:

set classpath

Figure 4.3. Validating the version of the Java SDK and the type of JVM being used.

Figure 4.4 shows the output from executing this command.

Figure 4.4. Checking your CLASSPATH listings.

Identifying the classes the Java Virtual Machine (JVM) uses when running a Java application is not so easy. You can use the -verbose switch on the JVM to list all classes that are being used. You then have to sift through the output to check the environmental setup.

Because many projects have PATH and CLASSPATH variables pointing to every conceivable product and version of that product, its actually good practice to create operating system scripts that will set your environment variable settings on demand.

Typically, with proper size development, three environments should be set up: development environment, test and validation environment, and production environment. In the development environment, developers would develop on their own desktop or laptop. The database and application server used could be running locally in the developer’s desktop/laptop or remotely in the development machine. Many companies have chosen to use Windows as the development environment on the developer’s desktop/laptop. If a remote application server or database is used, they would be running in Windows or Unix. This is where unit testing should be performed.

The test and validation environment should closely mirror the production environment in terms of hardware, OS, database and application server, and so on. This is where integration testing and validation is done. Typically, load testing and performance tuning is performed in this environment. The configuration of products used in the test environment are then very similar to the production environment.

Your project’s software and application environment to a large part determines your runtime environment. However, there are other important considerations such as product configuration, performance tuning, security, networking, and so on. Because many of the runtime issues have to be considered and reconsidered throughout the lifetime of the project it is important that you start out as simple as possible and stage the introduction of complexities as you continue with your development.

Namespaces, with their hierarchical framework, were invented to avoid naming ambiguities. A result of their hierarchical structure, they allow logical groupings of related parts. Namespaces are usually chosen to provide a functional decomposition of parts. In the end, the functional decomposition resolves the naming ambiguities. On the other hand, there are many classes in Java that have a very well-known API. Although namespaces will resolve conflicts, avoid using class names such as Vector, Hashtable, and so on, as they will only make the code harder to maintain.

In Java, namespaces are implemented using the package keyword. Every Java program file starts with a package statement.

The package statement is composed of one or more strings delimited by a period (.). For example, java.awt.color is the package name for classes that control color in the Java Abstract Windows Toolkit.

For most business applications, namespaces reflect the organization of a company. The company name is usually near the top of the namespace. Next are the departments, divisions, and projects. The remainder of the namespace usually describes the application and its functional components.

In Java, the package name in a Java source file determines the relative on-disk location of the Java class files generated by the Java compiler. The Java compiler’s -d option determines the root directory of the class file output. The hierarchy defined by the package name is used to store the class files. For example, the class files for a Java source file with a package name com.mycompany.tools resides in the directory com/mycompany/tools relative to the project’s root directory. The full path of the parent directory of the com directory, for this example, would appear in the CLASSPATH.

The Java package name also determines the relative runtime directory structure for Java class files. The relative runtime directory structure is identical to that created by the Java compiler. A Java program runs under the environment of the JVM. The JVM uses class files generated by the Java compiler. The class files are found either from the CLASSPATH environment variable or from the -classpath command line option. Either way, the JVM finds its classes in a directory tree whose structure is dictated by the Java namespace.

There is another way the package name can be used to organize your Java environment. Although the package name does not impose any specific restrictions on the location of your Java source files, the way the Java compiler and the Javadoc utility work strongly suggests that source files reside in a directory with the same structure as the Java namespace. When Java source files are stored in a directory tree reflecting the package name hierarchy, it can perform dependent compilation. That is, it can find dependent source files, compare them with existing class files, identify those that are out-of-date and if necessary, recompile sources. The Java compiler can only use its make-like feature when Java sources are stored by their package names. In addition, the Javadoc utility only works properly if the source is stored according to the package name hierarchy.

In summary, namespaces resolve naming conflicts, logically separate Java files into functional units, determine the compile and runtime relative class file locations, and determine the relative location of the Java source files.

Let’s look at an example of how to use namespaces in an application. We want to build a foreign exchange application for a financial services company. The company name is FXBank and its Web site is fxbank.com. FXBank has a corporate standards group that has developed a number of common services (such as security, application logging, common functions, and constants) for all software projects within the bank. Our project name is unique within the company. Our project has developed a number of classes shared by programs within the project. We are working on the foreign exchange application that enables traders to book trades. During development, we have discovered that classes and methods, while not usable by the rest of the project, are referenced throughout our application.

The Sun standard suggests that our package name begins with com.fxbank. The project name is Xtrader. The application we are writing is a trading kiosk or Kiosk for short. The package name at the application level is com.fxbank.xtrader.kiosk^[i]. By following our recommendations, the namespace layout for package names, classes, and source files are the same. Figure 4.5 shows the namespace represented as a directory structure.

Figure 4.5. The namespace represented as a directory structure.

In this directory structure,

The data and configuration files should be stored in a hierarchy dictated by the Java package names. If you are using data or configuration files that need to be available at runtime, those files can be placed in your CLASSPATH.^[ii]

Java programs have access to all files, not just class files, in their CLASSPATH.

The following code snippets demonstrate how to read files from your CLASSPATH. The first snippet, given in Listing 4.1, opens a file, reads the first line, and then displays the result. Listing 4.2 demonstrates how to load a Java properties file into your program and then how to read the property value with a key of "database". Both code snippets require that the file, test.config, be in the same directory as the class that is reading the file.

BufferedReader br = new BufferedReader(new InputStreamReader(
this.getClass().getResourceAsStream("test.config")));
System.out.println(br.readLine());
br.close();

BufferedInputStream bis = new BufferedInputStream(
this.getClass().getResourceAsStream("test.config"));
Properties prop = new Properties();
prop.load(bis);
System.out.println(prop.get("database"));
bis.close();

In summary, choose a namespace that represents your organization and application and apply that pattern as a standard.

Naming rules standardize the look and readability of the source code. The rules described in Table 4.1 provide a good starting point for most projects.

package com.mycompany; // NOT com.myCompany

class MyClass // NOT class myClass

class MyActionListener // NOT MyActionClass

interface MyInterface //NOT myInterface

class HandleitException extends Exception // NOT class HandleIt

long bigCounter; //NOT long BigCounter

Object[] myObjs; //NOT Object myObjs[];

int callNow() //Not int callnow()

int finaAllProducts() //NOT locateAllProducts()

static String FIRST_NAME="Gerald"; // Not firstName

Formatting rules help standardize the layout of the source code. The following rules are sufficient for most projects:

Comments provide a mechanism to convey information about a program that cannot be done using the Java programming language. Ideally, comment usage should fall into the following five distinct categories:

Javadoc comments consist of special delimiters and tags that when placed in source code can be used by the Javadoc utility to generate HTML pages describing classes, inner classes, interfaces, constructors, methods, and fields. That is, Javadoc enables you to create user documentation from source code comments. The generated HTML pages are available to other programmers on the project. Javadoc comments promote good communication between programmers and their usage is strongly recommended.

Javadoc comments begin with a delimiter, /** and end with another delimiter, */. The lines between these two delimiters consist of a description of the element and special tags that direct the Javadoc utility how to format the output. Because the generated output consists of HTML text, you are allowed to include HTML tags. The general form of Javadoc comments is given in Listing 4.3.

/**
  *   Description
  *
  *   @tag comment for the tag
*/

You should consider using the following Javadoc guidelines:

/**
  *
  *    Descripion of class or interface
  *
  *    @author Name of author. There can be multiple author lines.
  *    @version Version and date string. Use the source code control's version number.
  *    @see reference (you must have access to source code)
*/

/**
  *
  *    Descripion of inner class, inner interface, or variable.
*/

/**
  *
  *    Descripion of method
  *
  *    @param param1 Description of first parameter.
  *    @param param2 Description of second parameter.
  *    @param paramn Description of nth parameter.
  *    @return Description of return value.
  *    @throws Exception class name. Conditions when exception is thrown.
*/

The program layout is the pattern for how source code files should be constructed. Source code files should be based on a coding template. A sample template is presented in Listing 4.7.

The following elements are listed in the order they appear in the template file:

/*
 * SourceTemplate.java
 *
 * Copyright 2000-2001 ThisCompany, Inc.
 * All rights reserved.
 *
 * This software is the confidential and proprietary information
 * of ThisCompany, Inc. ("Confidential Information"). You
 * shall not disclose such Confidential Information and shall use
 * it only in accordance with the terms of the license agreement
 * you entered into with ThisCompany.
 */

//package name
package thiscompany.thisproject.thisapplication;

//import java package

//import javax package

//import product API packages

//import company API packages

//import project specific API packages

//import application specific API packages

/**
 *
 * This sample source header file describes the structural layout of all Java
 * programs. You can include HTML within this section. In particular,
 * common use is made of
 * <i>italic</i>
 * <code>monospaced font for code</code>
 * <pre>display text how it appears, with spaces, line breaks, and so on</pre>
 *   <b>boldface<b>  <p> - empty paragraphs for spacing
 *
 * @author  Joe Programmer
 * @version %I% %G%
 * @see     Collection
 * @see	          Collections#sort
 *
 */
public class SourceTemplate
{
    //Constants
    public static final String PUBLIC_CONSTANT="Public";
    private static final String PRIVATE_CONSTANT="Private";

    //Static variables
    private static int instanceCounter;

    //Instance variables

    //Static initializer

    //Instance initializer

    //Constructors
    /**
     * Constructs a new SourceTemplate with the command line arguments.
     *
     * @param      args  The command line arguments specifying the
     *                   work to be done
     * @throws     Exception
     */
    public SourceTemplate(String[] args)
    {
    }

    //Methods

    /**
     * Constructs a new SourceTemplate with the command line arguments.
     *
     * @throws     Exception
     * @return     Text message describing the final result
     */
    public String execute()
    {
        return "";
    }

    //Finalizer

    //Main

    /* This main is only for testing so I should not go into Java doc
    */
    public static final void main(String[] args)
    {
        try
        {
            SourceTemplate st = new SourceTemplate(args);
            System.out.println(st.execute());
        }
        catch(Exception e)
        {
        }
    }

Following standard coding practices is very important for software maintenance. It is very likely that many months after the code was first written, someone will have to fix bugs or add features to the software. Code that is well written makes this task much easier. Java developers have come to expect a common coding style when viewing Java source code. This style was first introduced by Sun and can be viewed on the Internet at http://java.sun.com/docs/codeconv. Virtually all source code found at the java.sun.com Web site follows these coding conventions.

This section provides a list of general and specific rules that should be followed when writing production-grade Java programs:

There are many facets to optimization: system tuning, database design, optimizing the logical flow within a program, and so on. When doing J2EE development, the performance and scalability of the system can be tuned at the JVM, OS, Database, and Application Server level without any application code change. Industrial-strength J2EE application servers such as WebLogic Server provide many tuning parameters to improve the J2EE applications’ performance and scalability. Therefore, one should not be caught up in performance optimization early on in the project development life cycle. Developers should be focused on the functionalities of the systems. During performance tuning, if the bottlenecks are narrowed down to the application code, then the code needs to be rewritten. This section covers recommended optimization practices for the Java programming language. These practices, when learned, should become part of your everyday coding habits.

We recommend coding choices that promote efficiency, but not at the expense of readability. There are a number of obscure techniques for making code execute faster, but often the real benefits are marginal. First, the Java compiler’s optimizer can perform a number of these programming tricks.

Although your code optimization may be significant for a few lines of code, it is often very small within the context of the entire program^[iii]

Optimization techniques for the following Java elements are discussed in the following sections:

The three areas to be addressed for Java collections are synchronization, memory allocation, and storage efficiency.

Method modifiers affect the speed of execution for methods. Table 4.2 is a relative comparison of the cost of making method calls based on the modifier type.

As you can see synchronized methods require, because of locking, considerably more overhead static methods. Static, private, and final method calls are not polymorphic and are more easily aligned by the Java compiler or Hotspot.

One technique for simplifying code reading in a method is to decompose it into a group of simpler methods. An optimizing compiler may inline these methods because they are only used once and are private.

Many of your application methods are never going to be overridden. If this is the case, make the methods final. If necessary, the restriction can be removed later.

There are several issues regarding performance that you should be aware of when using objects:

Use Arrays, instead of Vectors or ArrayLists when the number of elements is not going to change. Array access is faster.

When copying arrays, use the System.arraycopy method because it is 2–10 times faster than copying the elements in a loop.

There are a number of small optimization techniques, such as placing an array element into a temporary variable and referencing the temporary variable, instead of referencing the array element using its index. Directly referencing a temporary variable can be two or three times faster than referencing an array element through its index; however, the savings may be wasted because an optimizing compiler can do this for you.

Lastly, know what the Arrays class has to offer, which is a set of static methods that perform utility functions on arrays. There are four types of functions:

Loops can be a source of poor performance because they may contain other programming inefficiencies repeated many times. The following are some recommendations for using loops:

A straightforward demonstration of the last recommendation is as follows. Suppose you optimize some code and are able, using a cryptic series of instructions, to make a part of the code execute twice as fast as before. If these operations only consume 1% of the total processing in the loop, the overall performance gain is only .5%. You have not gained much by adding the difficult-to-maintain code.

There are a couple of less straightforward techniques for improving performance, but these may be of dubious value. Here are some techniques we do not recommend:

Although the loop variable computation in the second construct is up to two times faster than the first, it is hard to read. More importantly, the processing in the loop and not the comparison and index increment is much more likely to determine how long the loop takes to finish.

String usage is one of the easiest places to program inefficiently because strings are so easy to use.

There are four recommendations we have for optimizing the usage of strings.

String s4 = new StringBuffer().append(s1).append(s2).append(s3).toString();

s4 = s1 + s2 + s3;

// HashMap for storing String
private static final HashMap rules;
// create Strings for comparison and int values
private static final String[] _validOnes = {
        "valid#1",
        "valid#2", etc.}


public static final int VALID01=0;
public static final int VALID02=1; etc.
// initialize the HashMap
static
{
    rules = new HashMap();
    rules.put(values[VALID01],new Integer(VALID01));
    rules.put(values[VALID02,new Integer(VALID02); etc.
}

// Switch construct
//Get String s1 from elsewhere, a method call or an argument
int val = ((Integer)rules.get(s1)).intValue();
switch(val)
{
  case VALID01:
  {
    //do something
    break;
  }
  case VALID02:
  {
    //do something
    break;
  }
// additional cases follow

Synchronization is a mechanism used to allow multi-threaded programs to perform multiple sequential operations as a single atomic operation on shared data structures. Synchronization is necessary to prevent another thread from changing the value of the object’s attributes while an atomic operation is being performed. However, synchronization degrades program performance because of the overhead of locking objects and the side effect of placing threads in wait states, thus preventing other useful work from being done.

Although synchronization is simple to set up, it is difficult to get right. That is why Enterprise Java Beans (EJB) uses a single-threaded model. This section discusses some important considerations when using synchronization:

The Java I/O system provides the capability to transfer objects across a data stream through serialization. This is the mechanism that RMI uses to transfer parameters and return values between the client and remote object. It is very easy to make a class serializable by simply indicating that it implements the Serializable interface in its class declaration. The Serializable interface is fairly unique because it does not define any methods to be implemented. You are simply allowing the class to be cast to a Serializable object. Directly related to serialization is the Java keyword transient.

Basically, during serialization, all non-transient attributes of the object are converted into a data stream. During deserialization, an object is created and the non-transient attributes are initialized from the data stream. Any attributes that do not need to be stored persistently, because they are always initialized in some other manner, should be declared transient. This will greatly improve the speed and efficiency of the serialization process.

Serialization can be controlled by the class itself by implementing readObject() and/or writeObject() methods. The ObjectInputStream uses reflection to determine if the object has implemented readObject() or writeObject(). This mechanism can be used to initialize transient attributes when the object is deserialized. In the same manner, ObjectOutputStream will call the object’s writeObject() method if it exists. The readObject() method typically calls the defaultReadObject() followed by additional initialization that the class requires. The writeObject() method calls defaultWriteObject() followed by additional serialization that the class requires.

An example showing the implementation of serialization is shown in Listing 4.9.

public class TransientExample
{
    private String str;
    private transient String transString;

    // default constructor
    public TransientExample()
    {
        str = "hello";
        initTransients();
    }
    // initialize transients
    private void initTransients()
    {
        transString = "this string is transient";
    }
    // control serialization
    private void readObject( ObjectInputStream stream )
        throws IOException, ClassNotFoundException
    {
        System.out.println( "TransientExample is being de-serialized" );
        stream.defaultReadObject();
        initTransients();
    }
    // if writeObject() only calls defaultWriteObject()
    // there is no need to provide this function
    private void writeObject( ObjectOutputStream stream )
        throws IOException
    {
        System.out.println( "TransientExample is being serialized" );
        stream.defaultWriteObject();
    }

There are very few recommendations directly related to garbage collection (GC) because wasted memory is often the result of sloppy programming. Assuming those types of problems are fixed, there are still a couple of things that you can do to improve memory usage.

First, assign object references to null when they are no longer being used.

Local variables will not be eligible for garbage collection until the method they reside in exits. Going out of scope within a method does not place an object in the GC bin. Object references for important resources should also be set to null to speed up reclamation.

Secondly, if you expect your program to be idle, request the GC to run by calling the System.gc method.

When compiling your program to generate classes for performance testing or deployment, use the -O (optimize) switch. The -O option directs the compiler to try to generate faster code by inlining static, final, and private methods. The code is strictly optimized for speed of execution, not memory usage. This option may slow down compilation, make larger class files, and/or make it difficult to debug. The -O option implicitly turns on -depend and turns off -g. The -depend option causes the recompilation on any source files on which a class may recursively depend. Without the -depend option, the Java compiler only automatically recompiles the source files that are directly depended upon.

The -O option informs the compiler that all compiled class files are guaranteed to be delivered and upgraded as a unit, enabling optimizations that may otherwise break binary compatibility. Use this option with discretion.

The Java compiler performs constant folding and eliminates dead code, and the javac documentation claims its inline static, final, and private methods (at its discretion!).

The major code optimizations occur in the JVM. Sun’s Hotspot JVM combines a dynamic compiler with a JIT framework that turns commonly referenced sections of byte code into compiled native code.

Most inlining occurs during the JIT phase because the JVM knows what is used and inlines only what is necessary. Hotspot even inline calls across virtual method invocations, something static optimizers cannot do. Hotspot uses generational garbage collection, which speeds up and smoothes out program execution. Hotspot and other JIT-based compilers can improve the execution speed of Java code 10 to 50 times.

The JVM can be configured to support applications with large memory requirements. The maximum size and the initial size of the garbage collection heap can be set using the JVM -Xmx and -Xms options respectively. The default value for both of these is 6MB. The stack size per thread can also be controlled using the -Xss option. The default value for stack thread size is 128KB.

When adjusting the memory options of the JVM confirm that the physical memory space allowed for processes by the operating system are consistent with the Java memory parameters. Otherwise, you may experience big performance degradations due to swapping.

In summary, when targeting your software for a production environment, follow these rules:

Incremental development is the practice of developing software in small, discrete stages comprised of program analysis and design, coding and code refactoring, testing, and incremental integrated deliveries.

For the purposes of this chapter, design refers to program design and not the larger arena of system design, which involves evaluating use-cases, UML diagrams, and so on, although the two are obviously dependent upon one another.

The process, referred to as the design-coding-testing-delivery cycle, is repeated many times during the development stage, as illustrated in Figure 4.6.

Figure 4.6. Design-coding-testing-delivery cycle.

Before a single line of application code is written, an operational and easy-to-use environment should be set up. The last thing you want developers to do is to troubleshoot environmental issues when they have timelines to meet.

This section presents a list of tasks that should be completed before application development begins:

Every Java programming project uses shared classes. Some of these Java classes are business-specific and others are more general. General-purpose classes include error message generation, logging, authentication, exception handling, string handling, and so on. Business-specific classes vary depending on the business.

Ideally, all common components should be in place before application development begins. However, some components are discovered along the way when a developer realizes the same code is needed in various places. Other components are planned, but writing the code requires a lot of work and you don’t want to delay the project.

Before starting application development, at a minimum, skeletal classes should provide features, such as error message handling and exception handling, that are used early in the development cycle.

Don’t worry about designing or coding yet. The developer needs to set up his environment, verify it works, and learn to use it.

After the system administrator has set up your account, log in and run the environment setup procedure. Familiarize yourself with the project directory structure. Examine the environment variables. In particular, look at the CLASSPATH and PATH variables to see which programs you are using and which Java classes are being used. Check the version of your JDK and make sure it is what you expect. Perform any other environmental checks you deem useful at this time.

Next, make sure your tools are installed and they are working at a minimal level. If you find problems, contact the tech support group. Because you are using a common environment, others will eventually encounter the same problems.

After the tools are working, set up any Web links to useful online documentation, such as J2EE, J2SE, and BEA WebLogic documentation or the projectwide documentation page. The Java Developer Connection provides the latest information about Java technology at its Web site, http://java.sun.com/jdc, as well as distribution of highlighted topics through e-mail. Specifically for the WebLogic developer, BEA offers an online developer program at http://developer.bea.com. For all documentation that addresses your project, if you need hardcopy documentation, gather it or have it ordered.

Read the short version of the build and source code control system documentation. Use the source code control system by setting up a local copy of the project sample application. Try checking software out and in, getting listings, and so on.

If you are learning a product, read the documentation, and, if possible, talk to colleagues and identify the aspects of the product that are relevant to your project. Read for feature functionality and not necessarily deep understanding. Go through the product tutorial. Read and test the product examples. It is strongly recommended to attend BEA product training courses either onsite or offsite.

When you understand the environment and the products well enough, it is time to examine the project’s sample application. Look over the source code, look at build files, look at the configuration files, and so on. Build and run the sample application and verify that it works.

Finally, create a HelloWorld application using the technologies relevant to your assignment. Keep this demo application in your prototypes directory for future reference.

Overall, you need to spend a few days (or more depending on the scope of the project) to look over the documentation and other resources so you understand the products and can effectively develop software.

After you understand how to use the products and the development environment, it is time to get started with application development. At this point, you should have a complete understanding of your project’s objectives and have worked out a preliminary software design.