|
Articles in this issue :
|
Struts
By Thomas Paul
Why we need a controller architecture
There are two basic architectures for JavaServer Pages (JSP) development. The first is a page-centric design that
allows requests to be made directly to a JSP. The problem with this approach is that it will lead to JSPs with
excessive embedded Java code.
The second, a Model-View-Controller (MVC) architecture variant often called Model 2, is a controller design that
uses servlets to handle requests and JSPs to handle presentation. This allows for easy separation of function.
Although this is an improvement over the pure JSP model, this design is not without problems. If we code a separate
controller servlet for each page, we can end up with dozens of almost identical servlets. If we code a single controller
servlet, we end up with a monolithic class with a huge if/else statement that can be difficult to maintain. What's
needed to solve this problem is a controller architecture that can handle the repetitive details while still remaining
flexible and easy to maintain.
Figure: Model 2 architecture
What is Struts?
Struts is an open source application framework that provides a flexible and easy to use controller architecture.
The nature of the framework helps to promote a Model 2 application architecture with clear separation of functionality.
Struts includes a controller servlet, JSP custom tag libraries, and utility classes.
Struts is being developed as part of the Jakarta project, sponsored by the Apache Software Foundation. Since it
is an open source project, it can be downloaded from http://jakarta.apache.org/struts
and used for free.
In this article I will explain the installation of Struts and discuss some of the basic functionality that it provides.
For purposes of this discussion, I will be working with Struts installed in Tomcat running on a Win32 platform.
To demonstrate some of the functionality of Struts we will code a simple logon function.
The Struts Architecture
Struts provides the controller that will serve as the entry point for all requests into our application. The controller
determines which Java class will handle a particular request by referring to an XML file that contains mappings
of URL paths to Java classes. For a class to be usable by the Struts controller it must extend the Struts Action
class. Struts will call the perform( ) method of the Action object passing it the Servlet request and response
objects as well as some Struts objects which we will discuss in more detail later.
In addition, Struts can also be used to run a form pre-processor to do simple form validation. This is controlled
through the same XML file. We will also discuss this topic.
Struts also has custom JSP tag libraries that can simplify JSP programming. Besides special functionality used
in Struts programming, custom tags can provide commonly used functionality such as iterating through a collection.
Since the Apache Project includes the development of common custom tag libraries, the Struts tag libraries may
change in the future.
Installing Struts
The installation of Struts is a relatively simple process. We will first create a directory structure in our Tomcat
installation that will allow us to create our test application. (In this example we are assuming that Tomcat has
been isntalled to a directory named c:\tomcat.) Under the webapps directory in the tomcat installation directory,
create a struts directory. Under that directory create two directories, jsp and WEB-INF. The
jsp directory will be used to hold the JSPs we
create for our application. Under the WEB-INF directory create two directories, classes and lib.
The lib directory will hold the struts.jar file. The classes directory will be used to hold
all the Java classes that we code. Under the classes directory, create a directory named test. Under
the test directory, create a directory called struts.
Now download the struts installation file. This is available as either a zip or tar file from the Struts homepage.
Uncompress the file. There are 20 files in this zip file but you do not need them all for your installation. Extract
all the files ending in .tld (there should be six of them) and copy them into the struts/WEB-INF
directory. Extract the struts.jar file and copy it into the struts/WEB-INF/lib directory. It must
be installed in the each application's lib directory. Note this warning from the Struts installation document:
WARNING - Do NOT add struts.jar to the classpath of your Servlet container in an attempt to avoid placing
it in the /WEB-INF/lib directory of each individual web app! Doing so will cause problems with ClassNotFoundException
exceptions.
So let me reiterate: You must place the struts.jar file in the "struts\WEB-INF\lib" directory. If you don't your application
will not work correctly. You will probably see this error: org.apache.jasper.JasperException: Missing message for key title.login
or you may see other errors.
You can also copy the struts.jar into the jre\lib\ext directory since you will need it to do compiles
of programs using Struts. You should also add the servlet.jar file to that directory if you haven't already
done it. You can find the servlet.jar file in the c:\tomcat\common\lib directory.
Once this has been completed, your directory structure and installed files (ignoring the other tomcat directories)
should look something like this:
Figure: Directory structure of a Struts installation in Tomcat
web.xml File
There are two XML files that we, as Struts developers, will need to maintain. The first is the web.xml file
for our application. This file is stored in the application WEB-INF directory. An example web.xml
file is shown in Listing 1.
The first section of this file identifies the Struts controller class, ActionServlet and provides parameters for
this class. The "application" parameter identifies a properties file that contains error messages used
by the application. The "config" parameter identifies the Struts configuration file (more on this later).
The second section of the web.xml file tells Tomcat when to invoked the ActionServlet. In our example, ActionServlet
will be invoked whenever a URL ending with ".do" is found. For example, http://127.0.0.1/struts/login.do
will invoke the ActionServlet.
The final section identifies the Struts tag libraries.
Struts Configuration File
Listing 2 shows a simple struts-config.xml file that is passed as a parameter
to the ActionServlet. It should be placed in the same directory as the web.xml file. The struts-config.xml
file can have several sections. The first section we will look at is the <action-mappings> section. <action>
tells Struts which class to invoke from the ActionServlet. Only the "path" and "type" are required
entries. The "type" tells Struts which Action class to invoke when a URL with the model of the "path"
is found. From the example in Listing 2, the URL http://127.0.0.1/struts/login.do
will cause the ActionServlet to run a method in the class "LoginAction".
The other tag inside the <action> tag is the <forward> tag. This tag gives a way to identify which
JSP should be given control by the Action class without coding it inside the class itself.
The Action Class
In order for a class to be entered in the <action-mappings> section and to be invoked by ActionServlet, it
must extend the class org.apache.struts.action.Action (see Listing 3). The ActionServlet
will execute the perform( ) method of the Action object. The perform method looks like this:
public ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, javax.servlet.ServletException
The ActionMapping and ActionForm objects will contain information found in the struts-config.xml <action-mappings>
and <form-beans> sections. The HttpServletRequest and HttpServletResponse objects are from the servlet.
The perform( ) method must return an ActionForward object which will tell the ActionServlet which JSP gets control.
You can either:
- create an ActionForward object giving the constructor a String representing the name of the JSP to invoke:
return new ActionForward("MainMenu.jsp");
- use the ActionMapping object passed into the perform method to get the JSP from the <forward> tag found
in the struts-config.xml file: return mapping.findForward("valid");
We will use the method 2 since it will make it easier to change the JSP without changing the Java class.
Listing 3 is a simple Action class. It instantiates a validation bean which validates
that the user has rights to the system. In real life this might connect to a database using JDBC or connect to
an LDAP server using JNDI or make calls to an EJB servers. If the user does not have rights the bean returns an
ActionError object. The LoginAction class then routes the request to the correct JSP based on what the validation
bean returns.
If you wish to run this example, follow these steps:
- Create the LoginBean.java file (Listing 6) and compile it. Notice that the
bean has a get and set method for each field that the JSPs will need.
- Copy the class file to c:\tomcat\webapps\struts\WEB-INF\classes\test\struts
- Create the LoginAction.java file (Listing 3) and compile it.
- Copy the class file to c:\tomcat\webapps\struts\WEB-INF\classes\test\struts
- Create the LoginForm.java file (Listing 4) and compile it.
- Copy the class file to c:\tomcat\webapps\struts\WEB-INF\classes\test\struts
- Create the LoginView.jsp file (Listing 7)
- Copy this file to c:\tomcat\webapps\struts\jsp
- Create the MainMenu.jsp file (Listing 8)
- Copy this file to c:\tomcat\webapps\struts\jsp
- Create the web.xml file (Listing 1)
- Copy this file to c:\tomcat\webapps\struts\WEB-INF
- Create the struts-config.xml file (Listing 2a)
- Copy this file to c:\tomcat\webapps\struts\WEB-INF
- Create the MessageResources.properties (Listing 5). This file contains the
text to be displayed on the labels and buttons in the form providing us with a simple way to internationalize our
form. Use for this purpose is optional.
- Copy this file to c:\tomcat\webapps\struts\WEB-INF\classes\test\struts
- Start Tomcat
- Enter http://127.0.0.1:8080/struts/jsp/LoginView.jsp in your browser and you should see a screen similar
to figure 1.
- Enter a user id of "admin" and a password of "admin" and you should see a screen similar
to figure 2.
Breaking Down the Action Class
Let's look at the main code of the perform( ) method:
First, we create our bean to validate the login information and make that bean available to our JSPs. We then
pass the HttpServletRequest object to the validation bean so that it can extract the fields it needs to validate.
LoginBean lb = new LoginBean( );
request.setAttribute("LoginBean", lb);
lb.setParameters(request);
We then call the validation bean to validate the information from the form returning to us an ActionErrors object.
ActionErrors is a collection object that can hold ActionError objects. In a moment we will see why we use ActionErrors
to report errors. We then add the ActionErrors object to the HttpServletRequest object to make it available to
our JSPs. The key we use (Action.ERROR_KEY) is a standard key for ActionErrors objects in Struts.
ActionErrors ae = lb.validate( );
request.setAttribute(Action.ERROR_KEY, ae);
Finally, we look at the ActionErrors object that was returned to us and if it is null or empty (either of these
can signify no errors in Struts) we forward to the main menu JSP. If the ActionErrors object contains an ActionError,
we pass control to the Login JSP.
if (ae == null || ae.size( ) == 0) {
return mapping.findForward("valid");
} else {
return mapping.findForward("invalid");
}
Why use ActionErrors?
If the LoginBean finds an invalid login was attempted, it executes the following code:
ActionErrors ae = new ActionErrors( );
ae.add("userId", new ActionError("error.invalid.login"));
return ae;
First it creates an ActionErrors object to hold the ActionError object it is about to create. Next, it creates
the ActionError object passing a String to the constructor. The String is a key from the MessageResources.properties
file (Listing 5). Then it adds the ActionError object to the ActionErrors collection
giving it a String representing which particular field is causing the problem.
But why go to all this trouble to create ActionError objects in the first place? The reason has to do with the
JSP. If we look at the LoginView.jsp we find this line:
<html:errors />
This tag will extract the information from the ActionErrors object and display all the errors neatly on the
form (see Figure 3). The tag will use standard keys from the MessageResources file to
display a header and footer around the error mesages. See the errors.header, errors.footer and error.invalid.login from the MessageResources.properties (Listing 5).
You can also use <html:errors property="userId" /> to display a particular message based
on the key used when it was added to the ActionErrors object. This is useful if you want to display the message
next to the field causing the error.
JSP Tags
If you look at LoginView.jsp, you will see that there are numerous references to the Struts tag libraries. For
example:
<struts:message key="heading.login" />
<html:form action="/login">
<html:text property="userId" size="10" />
<html:password property="passWord" size="10" />
<html:submit>
<bean:message key="button.submit" />
</html:submit>
Each of these can simplify the use of Struts, the writing of your JSP, and the internationalization of your
application.
struts:message will replace this tag with the matching text found in the MessageResources file. This can
simplify internationalization issues.
html:form will define the form tag with the listed action. The action is specified by using the path from
the struts-config.xml file. It will be replaced with the correct form (/login.do) before it is sent to the
client. The html:form tag will also populate the input fields with the current property values from the bean associated
with this form.
html:text and html:password will create either a text field or password field and populate it with
the specified property from the bean associated with this form.
html:submit will generate a submit button for the form. We can use a struts:message inside the html:submit
tag in order to specify the label on the button.
There are tags within Struts that allow you to create radio buttons, check boxes, and other form objects.
The ActionForm class
We have seen how the Struts architecture works and developed a simple Struts application. The one major piece we
have not looked at is the ActionForm class which provides a simple way to do basic form validation.
In most applications there are some basic validations that need to be done on data from a form. This may include
insuring that required fields are entered, that dates are in a valid format, that numeric fields contain numerics,
etc. Struts provides a simple mechanism using form beans to provide this level of validation. Form beans (any class
that extends ActionForm) should not connect to a database or provide complex validations.
Form beans will be given control by Struts before the Action class. If the form bean determines that the form is
invalid it should return an ActionErrors object containing an ActionError object for each error found. Struts will
then return the input JSP back to the user with the errors displayed on the form. The Action class will not be
invoked unless an empty ActionErrors object or a null is returned.
Listing 4 displays a sample form bean. A form bean must extend ActionForm and should
have a get and set method for each field on the form. Struts will run the validate( ) method of the form bean.
The validate( ) method looks like this:
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request) {
ActionErrors ae = new ActionErrors( );
if (userId == null || userId.equals("")) {
ae.add("userId", new ActionError("error.no.userId"));
}
if (passWord == null || passWord.equals("")) {
ae.add("passWord", new ActionError("error.no.passWord"));
}
return ae;
}
The code itself is fairly simple and should be familiar from the LoginBean.
To activate this form bean we need to add a few entries to the struts-config.xml file. Listing
2a shows the revised file. First we need to add a defintion for the bean itself:
<form-beans>
<form-bean name="login" type="test.struts.LoginForm" />
</form-beans>
Next we turn on validation for the login and define the input form. The input form is used by Struts to determine
which JSP to give control to when the form bean returns ActionErrors:
<action
path="/login"
type="test.struts.LoginAction"
name="login"
input="/jsp/LoginView.jsp"
validate="true">
<forward name="valid" path="/jsp/MainMenu.jsp" />
<forward name="invalid" path="/jsp/LoginView.jsp" />
</action>
Now whenever the login is attempted, LoginForm will run and validate that the required fields are entered before
control is passed LoginAction. If the fields are not entered then the form will be redisplayed and LoginAction
will not run. Figure 3 shows the output of a failed login attempt.
Figure: MVC architecture with example classes
Wrapping It Up
That is a brief look at the basics of Struts. There is much more to Struts and the custom tag libraries contain
a lot more functionality than we have touched upon in this article. I recommend that anyone doing servlet/JSP/EJB
development take a look at Struts. Even if you choose not to use it, I think it will give you some good ideas about
the proper way to build a Model 2 architecture.
Meanwhile, Struts development continues. The Struts custom tag libraries are being merged with the JSP Standard
Tag Library (JSTL). Struts for Transforming XML with XSL (stxx) is available. To keep up-to-date with what is going
on in Struts and to find out how others are using Struts, you can subscribe to the STRUTS-USER
mailing list.
Return to Top
|
Ant
What is Ant?
By Thomas Paul
Ant is a Java based build tool developed as part of the Apache Jakarta project. It can be downloaded from the
Ant home site: http://jakarta.apache.org/ant. Unlike make files, which
are operating system specific, Ant is designed to be as cross platform as Java. Ant uses Java classes and XML scripts
to provide an automated way to build applications and to be available on every Java compatible platform.
Ant (which stands for Another Neat Tool) was originally developed by James Duncan Davidson
as part of the Tomcat project. Ant was developed specifically to simplify the process of building Tomcat. When
Tomcat was donated to the Apache project, Ant went with it. It was soon realized that Ant was very useful and could
be used in any project and became a separate Apache development effort. The current release of Ant is 1.4.1 (as
of February, 2002).
What Ant can do
Ant is a build tool. But Ant will allow you to do much more than just build your code. Ant functionality includes:
- extract source from a version control system
- create directories
- delete directories
- compile code
- generate javadoc
- jar files
- copy files
- generate e-mail
- ftp files
- execute SQL statements
- run unit test
- or any other function that you might need!
Ant is fully expandable. It is open so that new functions can be added by simply writing a new Java class.
The easiest way to explain Ant is with an example so we will look at a typical build and deploy script and then
we will look at some code to create our own function.
Installing Ant
Ant is simple enough to install. First, download the binaries from the Apache Ant web site. If you intend on
writing your own Ant classes, you can download the source as it can be a useful guide to writing Ant classes. Next,
extract the files from the Ant zip file. Update your classpath to point to the ant.jar file which is found
in the ant/lib directory. According to the Ant installation documentation:
Note: Do not install Ant's ant.jar file into the lib/ext directory of the JDK/JRE.
Ant is an application, whilst the extension directory is intended for JDK extensions.
In particular there are security restrictions on the classes which may be loaded by
an extension.
Next, add the bin directory to your path. Set the ANT_HOME environment variable to the directory
where you installed Ant.
If everything is working, you should be able to type Ant at your command line prompt and get this response:
c:\>Ant
Buildfile: build.xml does not exist!
Build failed
Note: If you are running WinXP and are having problems getting Ant to run, you should download the latest
nightly build and not the current release version of Ant.
A Build Script
Ant requires the use of a build script to tell Ant what to do. The default name of the script is build.xml
but you can use any name you want. Let?s take a look at a typical build script.
<?xml version="1.0"?>
<project name="aag" default="compile" basedir=".">
Every Ant build file contains one project. The attributes on the project tag are the name of the project, the
default target to run when no target is specified on the command line, and the base directory to use when locating
files. Ant works best when relative directories are used. Here we are creating a project called ?aag?. The target
named ?compile? will run as the default (more on targets in a moment), and the base directory to locate directories
and files is the directory where this build file is located.
<!-- ===================================== -->
<!-- Global properties -->
<!-- ===================================== -->
<property name="name" value="aag" />
<property name="build" value="${basedir}/build" />
<property name="baselib" value=?/jdk/jre/lib" />
<property name="dist" value="${basedir}/dist" />
<property name="source" value="${basedir}/source" />
<property name="docs" value="${basedir}/docs" />
<property name="api" value="${docs}/api" />
<property name="tomcat" value="/tomcat/webapps/aag/WEB-INF/lib" />
<property name="tomcat-jar" value="/tomcat/webapps/aag/jar" />
Ant allows the use of properties to save values. In this section we create a series of properties that will
represent the various directories we will be using in our script. In this way, if we want to change a directory
we can change it in the property list and we won?t need to find each place in our script that we used that directory.
Whenever Ant sees ${AName} it will replace this with the associated property named AName. So value="${basedir}/build"
becomes value="./build"since basedir was defined in the project tag. value="${docs}/api"
will become value="./docs/api".
The Target Tag
<!--===================================== -->
<!-- Init -->
<!--===================================== -->
<target name="init" >
<tstamp />
<mkdir dir="${build}" />
<mkdir dir="${api}" />
<mkdir dir="${dist}" />
</target>
The section above is a target tag. Targets can be specified on the command line when executing Ant and
Ant will then execute the specified target. All commands within the target tag are executed in the order specified.
Within the init target, we first initialize our timestamp. tstamp will initialize three properties which
can be used within the build script. The DSTAMP property is in the format "yyyymmdd", TSTAMP
is in the format "hhmm", and TODAY is in the format "month day year". These properties
could be used, for example, to generate unique file names.
The next commands will create the directories required to compile and jar our application.
Compiling our code
<!-- ===================================== -->
<!-- Compile -->
<!-- ===================================== -->
<target name="compile" depends="init" >
<javac srcdir="${source}" destdir="${build}"
<classpath>
<pathelement location="${baselib}/mysql_uncomp.jar" />
<pathelement location="="${baselib}/struts.jar" />
</classpath>
</javac>
</target>
The next target is named compile and has the init target as a dependency. This means that if compile
is specified as the target of a Ant run, the init target will automatically run first. The compile
itself if fairly simple. Ant will compile each of the java files found in the source directory and place the class
files in the destination directory. Ant will automatically place the class files in the correct structure based
on their package. It will also skip compiling any java file that has already been compiled and has not been changed
but only if the source files are in a directory structure exactly matching the package structure.
Notice that the classpath to use for the compile can be specified with separate pathelement tags. It is
recommended that the classpath be specified within the compile tag so that your compile doesn?t rely on the classpath
being specified correctly outside of Ant.
Generating JavaDoc
<!-- ===================================== -->
<!-- JavaDoc -->
<!-- ===================================== -->
<target name="javadoc" depends="compile" >
<javadoc sourcepath="${source}"
destdir="${api}"
packagenames="com.aag.*" />
</target>
The next target is javadoc which is dependent on the successful completion of the compile target.
Since the compile target is dependant on the init target, specifying javadoc on the command
line will cause init , compile , and javadoc all to run. The javadoc tag will cause
JavaDoc to be generated for all classes in all packages that start with com.aag that are in the sourcepath
. The JavaDoc will be placed in the destdir . In this example, packages such as com.aag.io , com.aag.database
, and com.aag.database.pool will all have JavaDoc generated.
The Jar Tag
<!-- ===================================== -->
<!-- Jar and Copy -->
<!-- ===================================== -->
<target name="jar" depends="javadoc" >
<jar jarfile="${dist}/${name}.jar" >
<fileset dir="${build}" />
<fileset dir="${docs}" />
</jar>
<copy todir="${tomcat}" file="${dist}/${name}.jar" />
</target>
The next target is named jar and depends upon the successful completion of the javadoc target.
The jar tag will create a jar file. The name of the jar file is controlled by the jarfile attribute.
The files that are included in the jar file are specified by separate fileset tags. The copy tag
will copy the jar file into the tomcat webapps directory.
Cleaning Up
<!-- ===================================== -->
<!-- Remove build directories -->
<!-- ===================================== -->
<target name="clean" >
<delete dir="${build}" />
<delete dir="${docs}" />
<delete dir="${dist}" />
</target>
</project>
The final target is named clean and since it has no other target dependent on it, will only run if specified
on the command line. The delete tag will delete the specified directory.
The build script is terminated with a final </project> tag.
Running the Script
Here is the possible output if we ran this script from the command line with ?ant jar?:
>ant jar
Buildfile: build.xml
init:
[mkdir] Created dir: C:\JavaProjects\AntTest\build
[mkdir] Created dir: C:\JavaProjects\AntTest\docs\api
[mkdir] Created dir: C:\JavaProjects\AntTest\dist
compile:
[javac] Compiling 12 source files to C:\JavaProjects\AntTest\build
javadoc:
[javadoc] Generating Javadoc
[javadoc] Javadoc execution
[javadoc] Loading source files for package com.aag.io...
[javadoc] Loading source files for package com.aag.database...
[javadoc] Loading source files for package com.aag.database.pool...
[javadoc] Constructing Javadoc information...
[javadoc] Building tree for all the packages and classes...
[javadoc] Building index for all the packages and classes...
[javadoc] Building index for all classes...
jar:
[jar] Building jar: C:\JavaProjects\AntTest\dist\aag.jar
[copy] Copying 1 file to C:\jakarta-tomcat-4.0.1\webapps\aag\WEB-INF\lib
BUILD SUCCESSFUL
Total time: 6 seconds
Ant first created our target directories, then compiled our source, generated the JavaDoc, put everything into
a jar file, and then copied the jar file to our Tomcat installation.
Now we can clean up our directories by running ?ant clean?:
>ant clean
Buildfile: build.xml
clean:
[delete] Deleting directory C:\JavaProjects\AntTest\build
[delete] Deleting directory C:\JavaProjects\AntTest\docs
[delete] Deleting directory C:\JavaProjects\AntTest\dist
BUILD SUCCESSFUL
Total time: 0 seconds
Creating our own tasks
Ant comes with a rich collection of tasks, some of which we have discussed. There are additional optional tasks
available at the Ant home page. If none of these tasks meet your needs, Ant allows you to write your own tasks.
Writing your own task is not very complicated. What if we want to send the jar file that we just created to
one of our staff members who works from home. We don?t want to send this jar file in the clear since it contains
our top secret development work. We need to create a new task that can take a file, encrypt it, and then put it
into a directory where our developer can find it. The Java class to perform this function is Listing
1.
The process starts by creating a java class that extends org.apache.tools.ant.Task. The class must have
a default constructor. We need to create a setter method for each attribute we intend on adding to our tag. Finally,
we need to create an execute( ) method that does all the work.
public void setKeyFile(String keyFile) {
this.keyFile = keyFile;
}
public void setInputFile(String inputFile) {
this.inputFile = inputFile;
}
public void setOutputFile(String outputFile) {
this.outputFile = outputFile;
}
Each of these setter methods relates to an attribute on our tag:
<crypto keyFile="key.ser"
inputFile="${dist}/${name}.jar"
outputFile="${dist}/${name}.secret.jar" />
When the execute( ) method runs it will have access to all the attributes that were specified within
the crypto tag.
The execute( ) method must be declared to throw org.apache.tools.ant.BuildException. No other
exceptions can be thrown. The constructor for BuildException allows for the wrapping of other excpetions:
} catch (Exception e) {
throw new BuildException("Problem with cipher", e);
}
The only thing left to do is to specify in the build script the actual name of the Java class. This is done
with a taskdef tag which is normally specified in the section with our global variables.
<taskdef name="crypto" classname="com.tom.ant.Crypto" />
The complete script is specified in Listing 2.
The Future of Ant
Ant development continues and Ant 2.0 is currently being developed. It is expected that build files developed
in Ant 1.4 will not work in Ant 2.0.
That wraps up our brief look at Ant. If this article has interested you in Ant, you should visit the Ant home
page and look at the documentation. Ant contains many more features than what we have seen in this article. I hope
that this has given you a flavor for the capabilities of Ant and the simplicity of using Ant to build applications.
If you are interested in Ant, I recommend that you sign up for the Ant user list available here: http://jakarta.apache.org/site/mail2.html.
Return to Top
|
|
Cindy's Segment - a Whimsical View of the World
Segment 1:
Lifestyles of the Rich and Object-Oriented
Or -
Not all Variables are created Equal
Imagine a world where all is clean and bright. Suddenly a call to glory goes out and in response, into this world comes a Mighty Class. As all good Classes do, the first thing that happens is that a ClassFile Castle is built to protect the good subjects of the class.
Now, this ClassFile Castle is built with a certain amount of storage space, of course. There is space in the Castle for class variable storage, where the Elite Static Variables can store their primitives or references. And there is space in the courtyard for literals to mill around and pool together.
There is a Castle Library where special information about related kingdoms is kept.
In addition, there is an area just outside the Castle, set aside for the Parliament, affectionately known as the Method Area. This area is a reserved place for all Royal decrees to be kept. Of course in JVMLand, the only behaviors that are allowed are those documented by royal decree. There are regular method decrees that dictate the behavior of the objects, and then there are the powerful Static decrees (also known as Static methods) that speak of things that only the Mighty Class can do.
Being a good and kind ruler, the Mighty Class allows his subject members to build Object Homes in the suburbs, outside of the Castle. The suburbs are called "The Heap". As each new object comes into being, a Home on The Heap is built, and these homes also have a certain amount of storage. So as to be fair, each and every home under the rule of this Mighty Class has exactly the SAME amount of storage, where each objects member variables can keep their primitives and references. The member variables in each Object Home is often called the objects fields, but I would call them storage closets.
And so the subjects were happy in their Object Homes, with plenty of space to hold their member variables and all of their behaviors dictated in the Method Area. And they have at their disposal all the resources of the ClassFile Castle.
But there is a dirty little secret going on in JVMLand. - - - Not All variables are created equal.
Sure, there are Elite Static variables being kept in the Castle, knowing that the Castle will probably last as long as all JVMLand. Yes, there are member variables snug in their Object homes, secure in the knowledge that as long as the Object Home is never completely abandoned, there will be a place for that member variable to live. But what no one ever talks about, what is whispered behind closed doors, is what happens in the Method Area.
When a Method is invoked, be it by one of the objects or by the Class itself, there are variables that are created automatically, on the fly. These poor creatures are never given a proper home. They are just assigned a slot on the stack, like a slave in a ship, where they toil away for the brief moment that their method is being executed, and then POOF!! They are tossed away like so much bit trash.
Oh the tragedy of it all! To have such a short existence, and to be treated with such distain. To be insulted by being called "Local Yokel"! To never have a classload or construction party, and so no one trusts you unless you are initialized right at the moment of your birth. What did they do to deserve that?
Not only is it bad enough that you know that you die as soon as your Method dies, but so often your scope of influence does not even last THAT long. If you happened to be a variable that is created in a block of code inside that Method, when the block is over, you are treated as though you were practically invisible. NO ONE knows that you are still there!!!!
Heck, if you are so unlucky as to be created in the initialization section of a For loop, when all the loops of that For stuff is over, your scope is over, you just sit around waiting for the end. Heaven forbid you should be created INSIDE one of the loops of a For loop, then your scope is only as long as the ONE loop.
Even your NAME is disposable. Heck, they figure that if you have no scope of influence, then they can't see you, and they can't get confused about who they are talking about, so what the heck, just use the same name over again. Bah!! No respect at all.
There is only one revenge that is sometimes available to the local variable. (Whisper this now) If they happen to have the same name as one of those high falutin' member or class variables or a parameter, during their short existence, they get to be "IT". If someone uses that name, it is the LOCAL variable that gets noticed. They get to over-shadow those big-shots with the stable life-styles.
And you know what, I think that they DESERVE IT.
So next time that you are thinking about how convenient it is to have Member Variables, remember the lowly Local Variable, and feel his pain.
Copyright ? 2002-2004. Cindy Glass. All rights reserved.
Graphics by Pauline McNamara and Stephanie Grasson
Next month - "When relatives move in" - or "Surviving your sub-classes"
Return to Top
|
You said "Certification"?
by Valentin Crettaz.
This article aims at guiding you towards the Java 2 Programmer Certification (SCJP2),
although some of the information provided here may apply to other certifications as well.
I also would like to provoke some kind of reaction. I'd like you to ask yourself some questions
about your actual Java level. Is the latter sufficiently high for getting further
or do you need to study more?
To get those questions answered, I'll first explain what a certification really is.
Next, I will talk a bit about what advantages
a certification can bring. I then enumerate some misconceptions that may arise when
people are talking about certifications.
After that, I will investigate the dos and don'ts, that is, tips to follow and traps to avoid.
Finally, since the main purpose of this article is not to describe in detail every step
you should follow to get certified, but to spare you some time by helping you to avoid going
the wrong direction, I won't give a detailed speech about preparation tips or where
to find mock exams, but I will merely give you some pointers on the web where you can
find some outstanding resources.
What is a certification?
To get the ball rolling, let's have a look at the first paragraph on the
Sun Education web site:
This certification is for programmers experienced in using the basic syntax and
structure of the Java[tm] programming language.
Well, this sentence says it all: a certification is for programmers who already have a good
experience in programming with Java and are willing to go further under the hood investigate the
intricacies of the language.
A Java certification --and all certifications in general-- should not be seen as a way of learning
a field from scratch. It is more geared towards the improvement of one's already-acquired
knowledge. With that paper hanging on the wall of the living room, one might be taken more seriously
when talking about Java issues or when applying for a programmer position. Some will say,
"it's just a paper anyway". I would answer that this paper actually makes a difference. It's difficult
to assess one's knowledge of Java (or any other knowledge for that matter), but getting certified
brings you one step closer to credibility. There is a difference between saying "I know Java" and
actually knowing Java ("I know Java". "Yeah, me too, 'been on vacation there! Beautiful,
isn't it?").
I think you got my point.
The Fine Print
Recent discussions
(Is
Certification really worth it ? and
Opinions
on SCJP2 test) posted respectively in the
Programmer Certification
Study and the
Programmer Certification
Results forums kept my attention. What one can conclude after reading those discussions is that,
apparently, some people
want to get certified just for fun or to improve their Java knowledge. It also seems that some people
think certification is not worth a penny. Everyone's thoughts are legitimate, of course, I won't
argue with that. However, I assume that if you keep reading you believe in the value of a certification.
What is a Certification good for?
As mentioned in the previous paragraph, this question has been the topic of many debates.
There is an everlasting
tirade about how good multiple-choices exams can assess one's knowledge.
One party argues that a certification
doesn't prove anything while the other party claims that a certification helps evaluate
one's know-how. Well, both are right and wrong at the same time. To answer this question,
be aware that there are different ways of certifying people. Let's take a peek at
the Java example since this is what Javaranch
is all about. The Sun Education Center
delivers 4 different certifications relating to the Java Language:
- The Sun Certified Programmer for the Java 2 Platform (SCJP2);
- The Sun Certified Web Component Developer for the J2EE Platform (SCWCD);
- The Sun Certified Developer for the Java 2 Platform (SCJD);
- The Sun Certified Enterprise Architect for the J2EE Platform (SCEA).
The first and the second are so-called multiple-choices exams. They require you to
have basic knowledge of the Java Language, to know what it is composed of
and how to use its basic building blocks to produce correct Java code.
All you need after that is experience on the field, which when acquired,
leads you to the next more serious certifications briefly presented below.
As you may already know, there is no right way to code. There are almost always
many solutions. This is exactly what the next certifications are all about.
The third and the fourth are somewhat harder; they not only require you to think but
to think efficiently.
You are given a work assignment to fulfill and then you have to face a Java expert and
defend your design choices. Questions you might expect
during the follow-up exam could be: What are the advantages of using this class instead
of that one? What are the consequences of using it over another?
Now, it's clear that certifications like the first or the second less accurately assess
one's knowledge since it is a matter of learning. More or less, everyone is capable of
learning. However, certifications like the third and the fourth do require some outstanding
knowledge of the field since you cannot possibly get certified by guessing the answers
or by counting on chance.
This being said, it is obvious that both parties have legitimate beliefs.
SCJP and SCWCD are more commonly aimed at because (let's face the truth)
they are easier, after all, if you have a good memory and you are good at remembering
things you can be a SCJP (or SCWCD for that matter). Assuming what precedes, the first party
gets the credit in saying that such an exam doesn't prove much.
Their arguments don't hold, however, against SCJD and SCEA because it would take a miracle
for somebody counting on chance or on her ability to remember things to get certified.
Well, to sum up, there will always be people who disagree and that's better that way.
Otherwise how would the world evolve? Debates have ever been sources of evolution. No debates,
no evolution. Let's just conclude this paragraph by saying that if you are willing
to seek for certification, go for it, don't care about what people are going to say about
it, the bottom line is YOU want to get certified (or your manager says so). BUT, pay attention
to what follows!
Some Misconceptions
The certification path can be applied to many fields of study.
Apparently, some people still don't make a difference between a respectable cook and a
"grand chef". If you want to learn cooking then you take cooking 101 and learn the
basics of cooking. How to boil water to make macaroni? How to melt some cheese to get
macaroni and cheese? Then, when you are sick of macaroni and cheese and want to become
somewhat more experienced in cooking, you can take advanced cooking lessons where you are
going to learn how to make yummy gravies to pour on your 1/2 lb steak or how to make a good
stuffed Thanksgiving turkey.
Ever tried to build a house by beginning with the roof? No need to be a PhD to figure
out that the house doesn't stay upright long.
Well, the same applies to Java. First, you take Java 101 to learn the basics of the
language, and then, only then, you can get further.
That's right, one step after another.
Focusing on SCJP, it is not a way of learning Java at all but more a way of improving what
you already know of Java and learning some basic coding techniques that will make you stand ahead of the
herd of wannabes. Again, if you try to become a SCJP without knowing the basics of Java, either
you fail right away or you might get into trouble once hired and staring helplessly at your
computer screen. That's the harsh truth but it needs to be said, emphasized and not be left untold.
Take the certification seriously and don't look at it as some banal professional or
academic experience. Moreover, don't seek for certification because a friend of yours told you
so or because you want to fancy up your resume with a, well, nice logo. Instead, you should have a
profound attraction to the Java Technology itself and also want to promote it.
If you are asking yourself questions such as "What language does the word 'overloading'
come from?" or "What is a subclass?", then you probably should hit the books
because you are not ready. To pretend being eligible for SCJP, you should at least be comfortable
with basic object-oriented concepts on which the Java Language relies, that is you should be
able to answer questions like "what is an object?", "what is a class?",
"what is inheritance?", etc. If you don't know how to deduce the output of a given
code, then you don't know how to read code and you need more practice.
Now, if you don't know why String literals are not garbage collected or why
wrapper classes (Integer, Double,...) in the package java.lang
are immutable, don't worry because those are advanced topics which you will learn
during your certification study.
Another thing I've seen way too much is the ever-present advice "You can count on x% chance
during the exam". Two words: forget it! Let's be somewhat realistic here. If you are counting
on chance to help you, you are an unreliable person and way off the line. It is true, though,
that chance may help but no one should partly rely on it to get certified (the same advice holds
for any other kinds of exams).
A further issue is that apparently some people are complaining about the memorizing requirements
that the certification study involves. Let's face some facts:
- the act of memorizing has never killed anybody;
- we all have a brain and we won't even use half of it by the time of our death, so capacity
is not an issue either;
- And last but not least, time is money and everybody knows that the access time to a human brain
is way smaller than the
time it takes to open a browser and search the API; the more you know the faster it goes
(your manager will be happy), it's that easy. It doesn't mean that you have to know everything
by heart, it just
means that what is required to memorize for the certification exam are signatures of
methods and constructors which are members of heavily used classes.
Anyway, if you claim to be an experienced Java programmer then you probably wouldn't even
complain about this memorizing requirement since you most surely already know what is
required to know. The ones who complain are people who need some more learning
and are not ready for getting certified yet (If you have arguments against what I just wrote,
I'd be happy to hear them).
It doesn't hurt to learn more than required either, just to gain some technical culture.
If you think you satisfy the requirements stated above, then you may safely follow
the certification trail further.
Dos and Don'ts
I won't describe any specific method to follow for getting certified, you should build up
your own. Everybody is different; hence, everybody works according to a different method.
The first and most important thing is: DON'T SCHEDULE YOUR EXAM BEFORE YOU KNOW
YOU ARE READY!!!. That's pure nonsense. How can you know that you'll be ready by the
date you have chosen? What you will end up doing is getting more and more stressed because
you think you might not finish in time. Stress is bad; it only leads you away from your
original goal. Now, you are asking yourself, "how can I know that I'm ready?".
Good question! I'll answer that by the end of this article; just keep reading.
The next important thing to do is to organize yourself properly. That means:
- Be consistent. Don't learn 10 hours a day during 5 days and then nothing during 5 days
and then again 8 hours a day during 2 weeks. Define right from the beginning, the daily time
you will spend on the task. You may be able to adjust that duration after a while.
If you are not able to spend the same amount of time everyday (because of whatever
reason), then you should at least do a little something just to stay in touch with
the study.
- Don't overdo it. There is no need to work days and nights without taking some rest.
All this will achieve is to increase your stress level and we already know that this
is not good. If you are studying full-time for SCJP you shouldn't work more than 8-9
hours a day. Past that time, you will still be able to work, no questions about it,
but your learning capacity will be diminished. The symptoms may be that you remember having read
something but you can't recall what it was about or what it taught you.
- Prioritize and schedule. Read several times the
objectives list
and underline the topics which you feel you are already comfortable with in green and
the one you feel you need to work on in red. The final goal is to make all objectives appear
in green, that's simple. Assign each objective a
weight. The higher the weight, the less you already know and master about the objective.
Prioritize the higher-weighed objectives first, because those are the ones that may require
more time for you to assimilate.
Define a period in your schedule during which you will spend time on them.
- Get some resources. It is important to get several complementary resources, like
books, mock exams, forum archives, and articles. Everything that might be of help to you
during your preparation. Also, always compare resources against each other whenever
you have a doubt about something. It may well be the case that sometimes a book says
something and another says exactly the opposite. Be absolutely sure of what you learn.
You can always post a question if you are still in doubt after several comparisons.
- Review. Reserve enough time before the exam to review the objectives and eliminate
remaining weaknesses.
Once you have made yourself a nice organized schedule, you can begin the festivities. From now
on, no more political talks, I promise. Let's get down to work.
Resources
The first thing to feed into your browser's location field is the following address:
http://www.javaranch.com/maha/index.html.
This web site has been created by Maha Anna (short for Mahalakshmi Annadurai), an Indian
Electronics and Communication Engineer who got certified during the year 2000. She thought
that sharing her own certification experience on a website would be a great idea, which it is.
She enumerates
very good preparations tips, lists a great deal of mock exams and resources as well as
interesting discussions which happened at Javaranch. So, I strongly recommend you to point
your browser to that web site and benefit from it. Next, I will just elaborate some of the
tips she gave.
The next thing to do --which should already be done-- is to get the Java 2 SDK Standard Edition
(J2SE) so
that you may create your own pieces of code. I'd get the latest stable version which is, as of
this writing, 1.3.1, but version 1.2 is fine too. Lots of coding practice is the key to
mastering the language. Never underestimate that.I guess I will never manage to emphasize
this point enough. Every time you encounter a blurry concept, write some code, compile it, run
it, change some statements, re-compile it, re-run it, twist it, re-compile it, and so on until
you get the
point. You won't always get to the point quickly, though, since some topics are rather difficult.
If such a situation arises, that's the moment to point your browser to the
Programmer Certification
Study forum at
Javaranch and ask your
buddies for some piece of advice. But, by all means, DO NOT post a piece of code without
even trying to compile and run it first. That's pure laziness. Questions like: "what
is the output of this code?", or "will this code compile and run?" should be
banished. I have noticed lately that an ever-growing number of people in the SCJP forum are aware of
that too, and are simply answering a nice and killing "first try, then ask".
Seriously, the practice requirement is very important. The equation is simple: the more you code,
the more comfortable you are in analyzing Java code and the faster you are going to spot bugs.
The inseparable companion of the Java programmer is the Java Application Programming
Interface (API) documentation. A well-organized
documentation containing thorough information about all packages, classes, methods and
fields released with the J2SE. It's not something you read sequentially but it is more like a dictionary.
Use it. Answers to questions like: "what does the String's method concat()
do?" or "which methods are declared in class Thread?" can be found in the
API. Time is precious, so stop wasting yours (and other's!) and browse those marvelous API first.
Anyway, if you satisfy the requirements I stated above, you most probably already know all that. You
may not know about the Java Language Specification, though, which I'll talk about next.
The Java
Language Specification (JLS) is the "best" technical Java reference. On the
book's web site, it says:
The book provides complete, accurate, and detailed coverage of the syntax and
semantics of the Java programming language. It describes all aspects of the language,
including the semantics of all types, statements, and expressions, as well as threads and
binary compatibility. .
Wondering how a switch construct works? how forward references are managed? how class instances
are created? and much more. The JLS provides accurate and thorough explanations on all basic
foundations of the Java Language. Undoubtedly, THE reference. Be well aware, though, that the
JLS contains some cryptic parts which heavily rely on mathematical definitions. So if you
are not used to have mathematical books as bedtime readings you may want to either get used
to it or look for a more understandable reference presented next. Moreover, the JLS only handles
the java.lang package and does not
spend time on specific Java packages, like java.awt, java.util or
java.io. To get information about the later, you are better off consulting
specific books on the topic, the Java tutorial,
or books expressly dedicated to the certification which you can find at the
Javaranch Bunkhouse.
To briefly conclude, if you want your certification to be worthy, you have to prepare yourself
accordingly. Cheating is for weak people and it is not of much help anyway. Work seriously and
try to write as much code as you can, this is the only way to learn Java rapidly and efficiently.
If you believe in the value of your certification, focus and don't listen to troublemakers. Put
all your energy in your study and you'll see that it is worth it.
Written by Valentin Crettaz.
Reviewed by Marilyn deQueiroz,
Jane Griscti and
Dave Vick.
Return to Top
|
Movin' them doggies on the
Cattle Drive
It's where you come to learn Java, and just like the cattle drivers of the old
west, you're expected to pull your weight along the way.
The Cattle
Drive forum is where the drivers get together to complain, uh rather,
discuss their assignments and encourage each other. Thanks to the enthusiastic
initiative of Johannes
de Jong, you can keep track of your progress on the drive with the
Assignment Log. If you're tough enough to get through the nitpicking,
you'll see your name on the
Graduation Log.
And a shiny spur goes to...
I'm happier than a pig in slop to announce our latest graduates! Christie
Xu and Terence Doyle drove their way through OOP and is now
moseyin' on over to Servlets. Newcomer Sam Tilley rode hard and made
it through Java Fundamentals, time to lasso them objects in OOP! Great
job y'all!
Back from being out on the range...
Angela Poynton joined her fellow drivers out on the range after a long snooze in the
bunkhouse. Welcome back Angela!
Saddle sore...
Daniel Olsen and Jason Adam are itchin' to get out of the
JDBC saddle. Hang in there, graduation is just around the corner! Nitpicking is hard work too...
Let's all raise a toast of sarsaparilla to Marilyn
deQueiroz
and newbie picker Jason Adam for pickin' at them nits.
It's hard work keeping them all them drivers in line! Tips for the Trail…...
Are you one of the many who got that famous nitpick: "100
concatenations - any room for optimization here?" Loops are a powerful tool, but can get messy real quick, especially when
it comes to performing operations. Try to think of ways you can move
an operation - or its result - out of the loop. This will help in
optimizing the resources needed by your program!
Written by Jason
Adam and Pauline
McNamara
Return to Top
|
Book Review of the Month
Java Tools for Extreme Programming
by Richard Hightower, Nicholas Lesiecki
|
|
|
You can happily ignore the main title of this book. Sure there's a nod
toward extreme programming, but that's not what this book is really all about.
This book is a fine introduction to a whole bunch of really useful tools to
boost your Java and especially J2EE programming. And all the tools can be
downloaded, source code and all, for free! There are too many tools to list
here, but they include the best-of-breed Ant build system, JUnit, HTTPUnit,
ServletUnit and Cactus test frameworks, load and performance analysers and some
great libraries for interacting with other servers.
Two major test cases are carried through the book to show the benefits of each
approach. Each tool covered gets at least a chapter of tutorial, and some of
the major ones also get an appendix of API and configuration information.
This book was almost too useful to review. It's been open on my desk from
almost the minute I got it and has greatly improved many aspects of my
development process. If you want to get up to speed quickly and practically on
a load of useful, powerful, tools - get this book. Everyone I've shown it to
has wanted their own copy ...
(Frank Carver - Sheriff, February 2002)
More info at Amazon.com ||
More info at Amazon.co.uk
|
Chosen by Cindy Glass and Madhav Lakkapragada
Return to Top
|
February Giveaways
For more information on JavaRanch's Giveaways see Book Promotion Page.
Return to Top
|
March News
JavaRanch has added a new forum to better assist people in their hunt for information.
Object Oriented Scripting - OO Scripting Languages, Python, Jython, Ruby, jRuby etc. and the Use of BSF
As always JavaRanch is dedicated to providing you with the best source of information on Java Programming and Engineering.
Return to Top
|
Managing Editor: Carl Trusiak
Comments or suggestions for JavaRanch's NewsLetter can be sent to the NewsLetter Staff
For advertising opportunities contact NewsLetter Advertising Staff
|
