Development Environment

---

Once the basics of getting the system up and running on the network are out of the way, it's time to go about the business of setting up the software for which the machine is actually intended to be used. That's the topic of this section.

Installing the Core Development Tools

As I mentioned at the beginning of this chapter, this case study system is primarily intended to be used as a platform for developing Java 2 Enterprise Edition (J2EE) applications. However, some additional tools that aren't strictly Java-related are still pretty useful to have around.

Table 15-1 lists several common programs, their purposes, and the RPM package that includes them. Generally, these tools will be extremely familiar to software developers (whose jobs revolve around them) and familiar to system administrators (who frequently have to use them to install software, as discussed in Chapters 8 through 13).

Table 15-1: Core Software Development Tools

TOOL	RPM PACKAGE	DESCRIPTION
gcc	gcc-2.96-110.i386.rpm	GNU compiler collection; includes compilers for common languages such as C, C++, Fortran, and so on
libstdc++	libstdc++-2.96-110.i386.rpm	Core libraries for C++ programs and the compiler
make	make3.79.1-8.i386.rpm	A build automation tool
flex	flex-2.5.4a-23.i386.rpm	The GNU Project's version of the lex lexical analyzer
bison	bison-1.35-1.i386.rpm	The GNU Project's version of the yacc compiler generator
strace	strace-4.4-4.i386.rpm	A program for debugging system calls
ltrace	ltrace-0.3.10-7.i386.rpm	A program for debugging calls to shared libraries

Configuring the Java Environment

Installing the Java environment is obviously the most important part of building a Java development workstation. This section describes the basics of the environment on the case study system. The next section describe additional software that is installed, based on the basic environment.

The basic environment is precisely that detailed in Chapter 13. To review, that chapter discussed how to create an environment in such a way that multiple Java Development Kits (possibly even from multiple vendors) can be installed "side by side." The separate installations are easy to switch between, and the environment also includes a mechanism for automatically setting environment variables (in particular the CLASSPATH variable) in users' shells. This environment is the core of this chapter's case study, so you absolutely should be familiar with Chapter 13.

Installing Additional Tools

Much of the power of the Java programming language comes from the wide variety of tools and libraries that are available. Developers use these libraries to boost their productivity and to share technologies and code. This section discusses some of these tools and describes how to add them to the basic Java environment framework set up in Chapter 13.

Automating Builds with ant

Earlier in this chapter in the section "Installing the Core Development Tools", the make tool was mentioned as one of the core development tools. Indeed, make is a venerable, extremely useful program. However, for a variety of reasons, it doesn't work seamlessly with Java programs. A popular alternative in the Java community is the ant tool, available from http://www.jakarta.apache.org/ant/index.html.

The ant tool is very similar to make, at a high level. The most immediate difference is that the format of its build files is in the Extensible Markup Language (XML), as opposed to make's use of a custom file format. Once you dig a bit deeper, you find additional advantages in ant that make is useful for Java applications; notably, it is extremely programmable, meaning that developers can extend it and embed it in their own Java applications.

Of course, this is a book on Linux systems, not Java programming tools, so I can't go into more detail than that. If you do need ant, you'll need how to install it. Fortunately, this is fairly straightforward. You should start by downloading a binary distribution of ant from http://www.jakarta.apache.org/ant/index.html. (You can download and build your own installation from source code, but with Java applications such as ant this is usually pointless, since Java binaries are designed to run on all machines.)

You'll quickly find that the ant distribution is a tarball (i.e., a .tar.gz file). To install it, you need simply extract the file with a command such as tar zxf jakarta-ant-1.4.1.tar.gz. The tarball contains the ant files in their own subdirectory, so when you extract the archive, its contents will be placed in a jakarta-ant-1.4.1 subdirectory of your current working directory. All this is easy and familiar; the real challenge is deciding where to install it.

In this case study, all paths lead to /opt/java. You'll recall from Chapter 3 that the /opt directory is intended for custom or system-specific installations of complete software packages. In this case, you're using /opt/java to contain all Java-related software. One goal is to keep similar software in the same location, to make it easier and more logical to manage as well as use. Another goal is to allow the ability to upgrade packages piecemeal, without having to remove older versions. (For various reasons, Java developers frequently need multiple versions of the JDK at once.) All this, of course, would be impossible if the contents of these software packages were mixed together in the /usr/local directory. For more details on all this, see Chapters 3 and 7.

Consequently, on the case study system the ant tool is installed in /opt/java/ant. This is the logical choice, since the JDK is installed in /opt/java/jdk. (Or more accurately, /opt/java/jdk is a symbolic link to the "default" JDK among potentially several JDKs that are installed at once; see Chapter 13 for details.) Since the ant tool itself includes shell scripts and other files that are executed, the /opt/java/ant/bin directory needs to be included in users' PATH environment variables. This means that the java.sh script discussed in Chapter 13 needs to be augmented for this case study. The augmented version of this file is presented as Listing 15-1 in a code sample later in this chapter in the section "Updating the Environment Scripts."

That's really all there is to installing ant. Using it, of course, isn't quite so easy, but then this isn't a book on Java programming! Hopefully, though, the installation process is pretty straightforward to you by now.

Developing Java Software with JBuilder

The basic Java environment as described in Chapter 13 is quite functional. The Java Development Kits installed include all the tools that are technically required to install software. However, many developers prefer to use enhanced tools known as integrated development environments (IDEs), which provide various productivity aids. One popular tool used on the case study system is Borland's JBuilder. This section discusses how to install this software, which you can find at http://www.borland.com/jbuilder/.

JBuilder is commercial software, so there is no source code distribution. Additionally, JBuilder includes a program that installs the software, rather than an RPM package or tarball. (In other words, JBuilder is a typical commercial software application.) Typically, JBuilder is installed from a CD or a program that is downloaded. JBuilder provides full details on the mechanics of this process, which is similar to the installation processes of OpenOffice that was discussed in Chapter 14. As with ant and discussed earlier in this chapter, the real question from an administrative standpoint is where JBuilder should be installed. Fortunately, the answer is just as easy as with ant: /opt/java/jbuilder. However, there's one extra tweak: It may be a good idea to install JBuilder in a directory whose name includes the version, such as /opt/java/jbuilder6 for version 6. This is because tools like JBuilder, as with the JDKs, sometimes need to have multiple versions installed at the same time. (You might also do the same thing with ant; however, on the case study system this didn't prove to be necessary.)

Once JBuilder is installed, it has to be configured. As with ant, JBuilder includes scripts to launch the application that need to be included in the users' PATH environment variables. The listing under the "Updating the Environment Scripts" section later in this chapter contains an updated java.sh file that includes support for ant and also includes support for JBuilder.

Installing Additional Java Libraries

One of the staples of Java developers are the standard Java Archive (JAR) files that contain libraries of code that developers can use in their applications. Some of these JAR files contain open source software, while others are commercial, but in either case they operate the same way. JAR files need to be added to a CLASSPATH environment variable so that they can be located by Java applications that require them. The Java environment constructed in Chapter 13 already fully supports a mechanism to automatically make use of these JAR files; essentially any JAR files that exist in / opt/java/packages are automatically added to the CLASSPATH variable by the login scripts.

This is generally pretty adequate. However, it bears another mention, in the context of installing additional JAR files. If you download a JAR file from the web (or perhaps build one yourself), all you need to do is place it in the /opt/java/packages directory and it will be automatically included in users' environments. Generally, this is all that's required to install Java JAR libraries—and of course, that was the point in constructing the script.

Updating the Environment Scripts

Listing 13-1 from Chapter 13 is a script that configures users' login environments to take advantage of the Java installation on the system. As I mentioned earlier in this section, this script needs to be updated to support the additional software.

Listing 15-1 is an updated version of /etc/profile.d/java.sh. (As with Listing 13-1, translating the script to other shell languages should be very easy, so it isn't covered here.) The only significant difference is the addition of two blocks toward the end of the listing that add ant and JBuilder to the users' PATH variables.

Listing 15-1: Updated /etc/profile.d/java.sh

 #!/bin/sh # set the JAVA_HOME to the default, unless it's already set if [[ "X"${JAVA_HOME} == "X" ]]; then     JAVA_HOME=/opt/java/jdk fi # add the JDK's bin directory to the PATH PATH=${JAVA_HOME}/bin:${PATH} # set the CLASSPATH; initialize to just "." (current working directory) CLASSPATH=. for jar in /opt/java/packages/*; do     if [[ "${jar}" == "/opt/java/packages/*" ]]; then         break;     fi     CLASSPATH=${CLASSPATH}:${jar} done # also add any JARs in the user's own java packages directory if [ -d ${HOME}/java/packages ]; then     for jar in ${HOME}/java/packages/*; do         if [[ "${jar}" == "${HOME}/java/packages/*" ]]; then             break;         fi         CLASSPATH=${CLASSPATH}:${jar}     done fi # add JBuilder and ant to the PATH if they are installed if [ -d /opt/java/jbuilder ]; then     PATH=${PATH}:/opt/java/jbuilder/bin fi if [ -d /opt/java/ant ]; then     PATH=${PATH}:/opt/java/ant/bin fi export PATH JAVA_HOME CLASSPATH 

Caveats and Enhancements

The information you just read works pretty well for most circumstances. However, there are occasions where you might run into some problems. This section points out a few snags you might encounter.

Using Many JAR Files

The script in Listing 15-1 adds JAR files to users' CLASSPATH environment variables automatically. Due to the way the Java Classpath mechanism works, these JAR files have to be specified with their full path names, even if they reside in the same directory. For example, the following CLASSPATH sets two JAR files, foo.jar and bar.jar:

 export CLASSPATH=/opt/java/packages/foo.jar:/opt/java/packages/bar.jar 

The problem with this scheme is that if too many JAR files are placed in /opt/java/packages (or the user's personal ~/java/packages directory), the value of the CLASSPATH variable can be very long. If it becomes too long, it will exceed the maximum limit that the shell (such as /bin/bash) allows for environment variables. If this happens, you may need to use a different technique.

Sun's Java Virtual Machine (JVM) also supports a mechanism known as the optional packages or standard extensions system. Essentially, this involves specifying one or more directories containing JAR files via a command-line option (which is the -Djava.ext.dirs option) to the java program. Here's an example of this:

 $ java -Djava.ext.dirs=/opt/java/packages:${HOME}/java/packages <classname> 

Unfortunately, this mechanism can only be used from the command line. That means that there's no easy way to configure the users' login environment to automatically use the Java extension mechanism. However, you can write an executable script to accomplish the task. This script should be placed in a directory which is in the users' PATH variables before the / opt/java/jdk/bin directory, so that the script is located first. (Otherwise the standard JDK's java program will be executed first.) One possibility might be to place the script in /usr/local/java. Listing 15-2 contains an example /usr/local/java script. The script simply sets the -Djava.ext.dirs argument and then executes the normal JDK java program.

Listing 15-2: Optional Replacement Java Script

 #!/bin/sh # Install this as /usr/local/java # set the JAVA_HOME variable if it's not already if [ "X$JAVA_HOME" == "X" ]; then    export JAVA_HOME=/opt/java/jdk fi # The JDK's ${JAVA_HOME}/jre/lib at a minimum is required by -Djava.ext.dir EXTDIR=${JAVA_HOME}/jre/lib@ # Add /opt/java/packages if there is one if [ -d /opt/java/packages ]; then     EXTDIR=/opt/java/packages@ fi # Add ~/java/packages if there is one if [ -d ${HOME}/java/packages ]; then     EXTDIR=${EXTDIR}${HOME}/java/packages fi # this causes the "@" to become a " ", and then " " to become a ":" # this is done to eliminate any spurious ":" at the end of the value EXTDIR=`echo ${EXTDIR} | sed 's/@/ /g'` EXTDIR=`echo ${EXTDIR} | sed 's/ /:/g'` # finally, execute the real bin/java exec ${JAVA_HOME}/bin/java -Djava.ext.dirs=${EXTDIR} $* 

Managing Ownership and Permissions

One thing you might find while using this case study is that it can sometimes become a pain to administrate. Java programmers are sometimes "high maintenance", meaning that they frequently need to install or upgrade new JDKs, add or remove packages, install additional tools, and so on. In other words, individual developers frequently need to install and remove things from /opt/java.

Such constant requests for installations and removals can become quite a burden on the administrator (or yourself, if you're administrating your own system). If the developers are self-sufficient, you may wish to allow them to manage their own Java installation.

There are generally two ways to do this. Obviously, the users could simply replicate the /opt/java configuration themselves, except in their own home directory. If you have multiple users, however, this wastes space in the form of each developer having her own copy of the relevant JAR files and software installations.

Another alternative is to assign the group ownership of the /opt/java directory to be a group containing all your Java users and then make the directory group writable. If you go this route, you'll also have to set the "sticky bit" on the group (using the chmod g+s command, as discussed in Chapter 12). The downside of this approach, however, is that your users now have write privileges to at least one directory in the /opt directory, which may be unpalatable to some administrators.

Both solutions to these problems have their own pros and cons. You'll have to choose the best compromise for your situation. You may find that the basic installation is adequate, or you might find that you need to use one of these optional techniques. It's up to you!

Using the Apache HTTP Server

This case study is intended for use in developing J2EE applications. Typically, this means building web applications. Frequently, developers doing this type of work use the Apache HTTP Server as their web server. In fact, this case study is one such system. This section describes the Apache configuration.

Actually, there isn't much to describe. The configuration used in the case study system is identical to the one described in Chapter 11. (That chapter discusses how to install Apache from source code.) The only addition to the configuration in that chapter is that the Tomcat Servlet engine plug-in was installed using the apxs command. (See Chapter 11 for more information on the apxs tool.)

Running J2EE Applications with Tomcat

Developing J2EE applications requires appropriate J2EE server software. However, Apache is only an HTTP server, so additional software is required to develop and run J2EE applications. Typically these servers will be linked with the Apache HTTP Server through Apache plug-ins.

This case study system is primarily used for developing Servlet and Java ServerPages (JSP) applications. Another common type is Enterprise JavaBean (EJB) applications; however, this particular configuration was not used for that purpose. The Servlet engine chosen was Tomcat, which is produced by the Jakarta project and is available from http://jakarta.apache.org/tomcat/index.html. (If you do need an EJB server, you may wish to check out Sun's J2EE reference implementation, which is available at http://www.java.sun.com/j2ee/download.html.)

Tomcat actually includes its own built-in HTTP server. This HTTP server is perfectly adequate—you may not even need Apache. However, the case study uses Apache nonetheless, to better mimic the production environment into which the applications are deployed.

Installing Tomcat is fairly straightforward. There are two components: a stand-alone server written in Java, and a plug-in for Apache that connects the HTTP server to the stand-alone Java server. You should be well equipped to handle both of these installations. Installing the Apache plug-in is accomplished using the standard apxs tool included with Apache and discussed in Chapter 11 (see Chapter 11 for details).

Installing the separate server program is also fairly straightforward. Essentially, it amounts to extracting the distribution into a directory of your choice and then modifying a configuration file for the server. (This makes the server portion of Tomcat similar to the flat-file server configuration similar to OpenSSH and discussed in Chapter 8.) In keeping with the standard used throughout this case study, Tomcat was installed into the directory /opt/java/jakarta-tomcat.

Installing Tomcat is easy—once you know how to install a similar server such as OpenSSH. The details are different (especially when it comes to the configuration file), but once you understand the general paradigm, the configuration file is easy. Tomcat's documentation should cover the rest of what you need to know.

So far, you've read about how to get your workstation on the network and how to configure a useful software development environment. However, there are additional realities to working in the business world. In the next section, you'll read about some useful software and techniques that will help you navigate the seas of business.

---