Monday 8 January 2007

Ant basics

Q: What is ANT?

Ø Java based build tool from Apache to create software products from source code
Ø De facto standard for building, packaging and installing etc of java applications
Ø It is configured with a build file that is an XML document
Ø Extended using Java classes






Q: How is it used?

Installation:

Ø Get the binary release from http://ant.apache.org/bindownload.cgi
Ø Set ANT_HOME environment variable
Ø Set JAVA_HOME environment variable
Ø Put the ANT bin directory on the PATH environment variable






Running:

Ø Type “ant” at the command line
Ø Automatically looks for the build.xml file in current directory to run
Ø Type “ant –buildfile ” to specify another buildfile to run
Ø Complete list of runtime parameters are
- buildfile buildfile – specify build file to use
- targetname – specify target to run (instead of running default)
- verbose, -quiet, -debug – Allows control over the logging information Ant outputs
- logger classname – Allows user to specify their own classes for logging Ant events










Q~: How buildfile is created or ANT tool is configured?

Each build file contains exactly one project and at least one target


Ø Project tag specify the basic project attributes and define the following
- name : name of the project
- default target : the default target to use when no target is specified
- basedir : the base directory from which all path calculations are done

Ø Each Target comprises one or more Tasks
Ø Task is a piece of executable java code (eg, java, jar etc)
Ø Tasks do the actual build work in ANT
Ø ANT has build in tasks and the ability to create new tasks
Ø Have the following structure
Ø Each Target comprises one or more Tasks
Ø Task is a piece of executable java code (eg, java, jar etc)
Ø Tasks do the actual build work in ANT
Ø ANT has build in tasks and the ability to create new tasks
Ø Have the following structure
Ø Target is a build module in ANT
- Each target contains task(s) that Ant to do
- One must be a project default
- Overall structure of targets:





Target tag specify the following attributes
- attribute = Description
- name* = the name of the Target
- depends = a comma separated list of targets on which this target depends
- if = name of the property that needs to be set in order for this target to execute
- unless = name of the property that must not be set in order for this target to execute
- description = a short description of this target’s function
Ø Each Target comprises one or more Tasks
Ø Task is a piece of executable java code (eg, java, jar etc)
Ø Tasks do the actual build work in ANT
Ø ANT has build in tasks and the ability to create new tasks
Ø Have the following structure

Ant overview: Writing own task (Task element)



Ø
Ø Each Target comprises one or more Tasks
Ø Task is a piece of executable java code (eg, java, jar etc)
Ø Tasks do the actual build work in ANT
Ø ANT has build in tasks and the ability to create new tasks
Ø Have the following structure Create a java class that extends org.apache.tools.ant.Task
Ø For each attribute, write a setter method that is public void and takes a single argument
Ø
Ø Each Target comprises one or more Tasks
Ø Task is a piece of executable java code (eg, java, jar etc)
Ø Tasks do the actual build work in ANT
Ø ANT has build in tasks and the ability to create new tasks
Ø Have the following structure
Ø Each Target comprises one or more Tasks
Ø Task is a piece of executable java code (eg, java, jar etc)
Ø Tasks do the actual build work in ANT
Ø ANT has build in tasks and the ability to create new tasks
Ø Have the following structure Write a public void execute() method, with no arguments, that throw a BuildException – this method implements the tasks itself


Properties

Ø Special task for setting up build file properties:
Example:

Ø Can use ${src} anywhere in build file to denote /home/src
Ø Ant provides access to all system properties as if defined by the task

Path Structures

Ø Ant provides means to set various environment variables like PATH and CLASSPATH.
Ø Example of setting CLASSPATH:





Integration with IDE

Most of the I DE’s like NetBeans, Eclipse, JBuilder, VisualAge, and almost any other Java IDE has Ant integration built in to the system
Refer to each IDE documentation to see how to use ANT with each IDE




Web development – ANT with Tomcat

Ø Tomcat comes with special Ant tasks to ease Web application development and deployment
Ø Copy $TOMCAT_HOME/server/lib/catalina-ant.jar to $ANT_HOME/lib
Ø Ant tasks for Tomcat:
- install
- reload
- deploy
- remove

MultiThreading - Part 2

Building programs around threads of execution—that is, around specific sequences of instructions—delivers significant performance benefits. Consider, for example, a program that reads large amounts of data from disk and processes that data before writing it to the screen (such as a DVD player). On a traditional, single-threaded program (the kind most client programs use today), where only one task executes at a time, each of these activities happens as a part of a sequence of distinct phases. No data is processed until a chunk of a defined size has been read. So the program logic that could be processing the data is not executed until disk reads are complete. This leads to inferior performance.
On a threaded program, one thread can be assigned to read data, another thread to process it, and a third to write it out to the graphics card. These three threads can operate in parallel so that data is being processed while disk reads are going on. And overall performance improves. Many other examples can be devised in which the ability to do two things at once will provide better performance. The Java virtual machine (JVM) is itself heavily threaded for just this reason.
This article discusses creating multithreaded Java code, a few best-practices for designing parallel programs, and some of the tools and resources available to developers. That's a lot to cover in one article, so I'll just highlight the salient points and direct you to resources for additional information.
Threading Java Code
All programs use at least one thread. In C/C++ and Java, this is the thread that is started with the call to main(). The creation of additional threads requires several steps: creating a new thread and then assigning it work. Once the work is done, the thread is automatically killed off by the JVM.
Java provides two methods for creating threads and assigning them work. The first of these is to subclass Java's Thread class (in java.lang package) and then over-ride the run() method with the thread's work function. Here is an example of this: public class SimpleThread extends Thread { public SimpleThread(String str) { super(str); } public void run() { for (int i = 0; i < 10; i++) { System.out.println(i + " " + getName()); try { sleep((long)(Math.random() * 1000)); } catch (InterruptedException e) {} } System.out.println("DONE! " + getName()); }}
This class subclasses Thread and provides its own run() method. That function runs a loop which prints a passed string to the screen and then waits for a random amount of time. After ten iterations of the loop, the function prints "DONE!", then exits, which kills the thread. Here is the main function that creates the threads: public class TwoThreadsDemo { public static void main (String[] args) { new SimpleThread("Do it!").start(); new SimpleThread("Definitely not!").start(); }}
Note the simplicity of this code: the function is started, given a name (which is the string the thread will print) and start() is called. start() will call the run() method. The results of this program are as one would expect: 0 Do it!0 Definitely not!1 Definitely not!2 Definitely not!1 Do it!2 Do it!3 Do it!3 Definitely not!4 Do it!4 Definitely not!5 Do it!5 Definitely not!6 Do it!7 Do it!6 Definitely not!8 Do it!7 Definitely not!8 Definitely not!9 Do it!DONE! Do it!9 Definitely not!DONE! Definitely not!
As can be seen, the output from the two threads is intermingled. In a single-threaded program, all the "Do it!" commands would have printed together, followed by all the "Definitely not!" writes.
Different runs of this program will generate different results. This uncertainty is due to two aspects: there is a random pause between iterations of the loop and, more importantly, because the timing of thread execution is not guaranteed. This is a key principle. The JVM will run the threads on its own schedule (which generally favors running them as quickly as possible, but there is no guarantee of when a given thread will be run). A priority can be associated with individual threads to make sure that critical threads are handled by the JVM before less important ones.
The second way to start up a thread is to use a class with the Runnable interface, which is also defined in java.lang. This Runnable interface specifies a run() method that then becomes the thread's principal function, similar to the previous code.
The general style in Java these days is to favor interfaces over inheritance. This rule of thumb is valid in this choice of options as well. By using the interface option, a class can still inherit (subclass) later on, if necessary. (This would occur, for example, if the class were to be used later as an applet.)
Implications of Threading
While threading enhances performance, it adds complexity to the program's internal operations. This complexity arises primarily from interaction among the threads themselves. It is important to become familiar with these issues, because as more cores are added to Intel® processors, the number of threads to use will grow correspondingly. If these issues are not understood when programming for many threads, difficult to find bugs will undoubtedly ensue. So, let's look at some of the issues and solutions.
Waiting on another thread to finish: Suppose we have an array of integers that we want to process. We could step through the array, one integer at a time, and perform the operation. Or, more efficiently, we could assign several threads so that each one would process some portion of the array. Suppose we had to wait for all threads to finish before moving on to the next step. To synchronize activities temporally between the threads, threads use the join() method, which makes one thread wait on another to complete. The joining thread (thread B) waits on the joined thread (thread A) to finish. An optional timeout in join() enables the thread B to move forward with the other work if thread A does not terminate within a given time frame. This provision touches on a core complexity of threading: the problem of waiting on a thread. We'll touch on this next.
Waiting on locked objects: Suppose we wrote an airline seat-assignment system. On large programs of this kind, it is common that a thread is assigned to every user connected to the software, such as one to every ticket clerk. (In very large systems, this is not always the case.) If two users are simultaneously attempting to assign the same seat, problems will arise. Unless special steps are taken, one thread will assign the seat while another thread is doing the same thing. Both users will think they have an assigned place on the flight.
To avoid two threads simultaneously modifying the same data item, we have one thread lock the data item just prior to modification. In this way, when the second thread comes along to make the modification, it will have to wait until the lock is released by the first thread. When this occurs, the thread will see that the seat has just been assigned, and the request for seat assignment will fail. The problem of two threads racing to get the seat assignment completed is known as a race condition, and it can wreak havoc when it occurs. Best practice is to lock any code that accesses a variable that is accessible to more than one thread.
There are several locking options in Java. The most common of these is the use of the synchronized keyword. When the signature of a method includes synchronized, only one thread can execute that method at any given time. The lock on the method is then released when the method finishes executing. For example, protected synchronized int reserveSeat ( Seat seat_number ){ if ( seat_number.getReserved() == false ) { seat_number.setReserved(); return ( 0 ); } else return ( -1 );}
is a method that can only be run by one thread at a time. This locking breaks the race condition described earlier.
Using synchronized is one of several methods for handling interactions between threads. Java release J2SE 5.0 adds several convenient ways to lock objects. Most of these are found in the java.util.concurrent.locks package, which should be examined carefully once you're comfortable with Java threads.
While locking mechanisms solve the problem of race conditions, they introduce new complexity. The most difficult situation, in this regard, is called deadlock. Suppose thread A is waiting on thread B, and thread B is waiting on thread A, then both threads will be blocked forever, which is why the term deadlock is so descriptive. Deadlocks can be very difficult to identify (they can be hard to reproduce), and so care must be exerted to make sure there are no dependencies of this kind between threads.
Using Thread Pools
As mentioned earlier, when threads finish executing they are killed off by the JVM and the memory allocated to them is eventually garbage-collected. The trouble with the constant creation and destruction of threads is that it wastes clock cycles, as creating threads does have distinct overhead associated with it. A common solution and best practice is to allocate a group of threads (called a thread pool) early in the program and then reuse the threads as they become available. Using this scheme, the function assigned to a thread at creation is to sit in the pool and wait for a work assignment. Then, when the assigned work is complete, the thread is returned to the thread pool.
J2SE 5.0 introduced the java.util.concurrent package that includes a pre-built thread pooling framework that greatly facilitates this approach. More information on Java thread pools, including a tutorial can be found here.
When designing threaded programs and thread pools, the question naturally arises as to how many threads should be created. The answer depends on how you plan to use the threads. If you divide the work across threads on the basis of discrete tasks, then the number of threads equals the number of tasks. For example, a word processor might use one thread for display (the primary program thread in almost all systems is the one entitled to update the user interface), one for paginating the document, a third one for spell checking, and a fourth for miscellaneous background operations. In this case, four threads are ideal and they provide a very natural way to write the software.
However, if the program—like the one discussed earlier—uses multiple threads to do similar work, then the optimal number of threads tends to be a reflection of the system resources, especially the number of execution pipelines on the processor and the number of processors. On systems with Intel processors that rely on Hyper-Threading Technology (HT Technology), there are currently two execution pipelines per processor core. The new multi-core chips have two processor cores per chip. Intel has indicated that future chips are likely to have more cores, in good part because additional cores generate more performance without substantially increasing heat or power consumption. So, pipelines are going to become more plentiful.
Using the arithmetic suggested by these architectures, on a dual-core Pentium® 4-based system, four execution pipelines will be available and so four threads will provide ideal performance. On a dual-processing Intel® Xeon™-based workstation, the ideal number of thread is four, because at present the Xeon chips offer HT Technology but no multi-core models.
Final Thoughts
When running threaded Java programs on Intel platforms, you will likely want to be able to monitor the load on processors and the execution of threads. One of the best JVMs for obtaining this data and managing how the JVM handles parallel processing is BEA's WebLogic JRockit. JRockit has the additional advantage of having been purpose-built for the Intel platforms and optimized by engineers from BEA and Intel.
Regardless of which JVM you use, Intel® VTune™ Performance Analyzer will give you a deep view into how the JVM is executing your code, including per-thread performance bottlenecks. A white paper on using VTune performance analyzer with Java is located here. This article has provided an overview of how threading works on the Java platform. As Intel continues shipping processors with HT Technology and releases more multi-core chips, pressure to obtain the performance benefits from these multiple pipelines will increase. And, as the number of cores increases, the number of pipelines will proliferate correspondingly. The only way to exploit there advantage is to use threads, such as those discussed in this article. And the benefit of threaded applications in Java will become even more clearly evident. The following section provides additional resources to help guide you along

Threading in Java - Tutorial1

Introduction to Java threads
A quick tutorial on how to implement threads in Java

This article describes how threads are implemented in the Java programming language. Before exploring the details of Java, a general overview of threads is needed.
Simply put, a thread is a program's path of execution. Most programs written today run as a single thread, causing problems when multiple events or actions need to occur at the same time. Let's say, for example, a program is not capable of drawing pictures while reading keystrokes. The program must give its full attention to the keyboard input lacking the ability to handle more than one event at a time. The ideal solution to this problem is the seamless execution of two or more sections of a program at the same time. Threads allows us to do this.
Multithreaded applications deliver their potent power by running many threads concurrently within a single program. From a logical point of view, multithreading means multiple lines of a single program can be executed at the same time, however, it is not the same as starting a program twice and saying that there are multiple lines of a program being executed at the same time. In this case, the operating system is treating the programs as two separate and distinct processes. Under Unix, forking a process creates a child process with a different address space for both code and data. However, fork() creates a lot of overhead for the operating system, making it a very CPU-intensive operation. By starting a thread instead, an efficient path of execution is created while still sharing the original data area from the parent. The idea of sharing the data area is very beneficial, but brings up some areas of concern that we'll discuss later.
Creating threads
Java's creators have graciously designed two ways of creating threads: implementing an interface and extending a class. Extending a class is the way Java inherits methods and variables from a parent class. In this case, one can only extend or inherit from a single parent class. This limitation within Java can be overcome by implementing interfaces, which is the most common way to create threads. (Note that the act of inheriting merely allows the class to be run as a thread. It is up to the class to start() execution, etc.)
Interfaces provide a way for programmers to lay the groundwork of a class. They are used to design the requirements for a set of classes to implement. The interface sets everything up, and the class or classes that implement the interface do all the work. The different set of classes that implement the interface have to follow the same rules.
There are a few differences between a class and an interface. First, an interface can only contain abstract methods and/or static final variables (constants). Classes, on the other hand, can implement methods and contain variables that are not constants. Second, an interface cannot implement any methods. A class that implements an interface must implement all methods defined in that interface. An interface has the ability to extend from other interfaces, and (unlike classes) can extend from multiple interfaces. Furthermore, an interface cannot be instantiated with the new operator; for example, Runnable a=new Runnable(); is not allowed.


The first method of creating a thread is to simply extend from the Thread class. Do this only if the class you need executed as a thread does not ever need to be extended from another class. The Thread class is defined in the package java.lang, which needs to be imported so that our classes are aware of its definition.
import java.lang.*;public class Counter extends Thread { public void run() { .... }}



The above example creates a new class Counter that extends the Thread class and overrides the Thread.run() method for its own implementation. The run() method is where all the work of the Counter class thread is done. The same class can be created by implementing Runnable:
import java.lang.*;public class Counter implements Runnable{ Thread T; public void run() { .... }}


Here, the abstract run() method is defined in the Runnable interface and is being implemented. Note that we have an instance of the Thread class as a variable of the Counter class. The only difference between the two methods is that by implementing Runnable, there is greater flexibility in the creation of the class Counter. In the above example, the opportunity still exists to extend the Counter class, if needed. The majority of classes created that need to be run as a thread will implement Runnable since they probably are extending some other functionality from another class.
Do not think that the Runnable interface is doing any real work when the thread is being executed. It is merely a class created to give an idea on the design of the Thread class. In fact, it is very small containing only one abstract method. Here is the definition of the Runnable interface directly from the Java source:
package java.lang;public interface Runnable { public abstract void run();}


That is all there is to the Runnable interface. An interface only provides a design upon which classes should be implemented. In the case of the Runnable interface, it forces the definition of only the run() method. Therefore, most of the work is done in the Thread class. A closer look at a section in the definition of the Thread class will give an idea of what is really going on:
public class Thread implements Runnable {... public void run() { if (target != null) { target.run(); } }...}



From the above code snippet it is evident that the Thread class also implements the Runnable interface. Thread.run() checks to make sure that the target class (the class that is going to be run as a thread) is not equal to null, and then executes the run() method of the target. When this happens, the run() method of the target will be running as its own thread.
Starting and stopping
Since the different ways to create an instance of a thread are now apparent, we will discuss the implementation of threads beginning with the ways available to start and stop them using a small applet containing a thread to illustrate the mechanics: Continued
and Source code
The above applet will start counting from 0 displaying its output to both the screen and the console. A quick glance might give the impression that the program will start counting and display every number, but this is not the case. A closer examination of the execution of this applet will reveal its true identity.
In this case, the CounterThread class was forced to implement Runnable since it extended the class Applet. As in all applets, the init() method gets executed first. In init(), the variable Count is initialized to zero and a new instance of the Thread class is created. By passing this to the Thread constructor, the new thread will know which object to run. In this case this is a reference to CounterThread. After the thread is created it needs to be started. The call to start() will call the target's run() method, which is CounterThread.run(). The call to start() will return right away and the thread will start executing at the same time. Note that the run() method is an infinite loop. It is infinite because once the run() method exits, the thread stops executing. The run() method will increment the variable Count, sleep for 10 milliseconds and send a request to refresh the applet's display.
Note that it is important to sleep somewhere in a thread. If not, the thread will consume all CPU time for the process and will not allow any other methods such as threads to be executed. Another way to cease the execution of a thread is to call the stop() method. In this example, the thread stops when the mouse is pressed while the cursor is in the applet. Depending on the speed of the computer the applet runs on, not every number will be displayed, because the incrementing is done independent of the painting of the applet. The applet can not be refreshed at every request, so the OS will queue the requests and successive refresh requests will be satisfied with one refresh. While the refreshes are queuing up, the Count is still being incremented but not displayed.
Suspending and resuming
Once a thread is stopped, it cannot be restarted with the start() command, since stop() will terminate the execution of a thread. Instead you can pause the execution of a thread with the sleep() method. The thread will sleep for a certain period of time and then begin executing when the time limit is reached. But, this is not ideal if the thread needs to be started when a certain event occurs. In this case, the suspend() method allows a thread to temporarily cease executing and the resume() method allows the suspended thread to start again. The following applet shows the above example modified to suspend and resume the applet.
public class CounterThread2 extends Applet implements Runnable{ Thread t; int Count; boolean suspended; public boolean mouseDown(Event e,int x, int y) { if(suspended) t.resume(); else t.suspend(); suspended = !suspended; return true; } ...}



CounterThread2 Example and Source code
To keep track of the current state of the applet, the boolean variable suspended is used. Distinguishing the different states of an applet is important because some methods will throw exceptions if they are called while in the wrong state. For example, if the applet has been started and stopped, executing the start() method will throw an IllegalThreadStateException exception.
Scheduling
Java has a Thread Scheduler that monitors all running threads in all programs and decides which threads should be running and which are in line to be executed. There are two characteristics of a thread that the scheduler identifies in its decision process. One, the most important, is the priority of the thread, the other is the daemon flag. The scheduler's basic rule is if there are only daemon threads running, the Java Virtual Machine (JVM) will exit. New threads inherit the priority and daemon flag from the thread that created it. The scheduler determines which thread should be executed by analyzing the priorities of all threads. Those with the highest priority are allowed execution before any lower priority threads.
The scheduler can be of two flavors, preemptive or non-preemptive. Preemptive schedulers give a certain time-slice to all threads running on the system. The scheduler decides which thread is next to run and resume() that thread for some constant period of time. When the thread has executed for that time period it will be suspended() and the next thread scheduled will be resumed(). Non-preemptive schedulers decide which thread should run and run it until the thread is complete. The thread has full control of the system for as long as it likes. The yield() method is a way for a thread to force the scheduler to start executing another waiting thread. Depending on the system Java is running on, the scheduler can be either preemptive or non-preemptive.
Priorities
The scheduler determines which thread should be running based on a priority number assigned to each thread. The range of priorities is from 1 to 10. The default priority of a thread is Thread.NORM_PRIORITY, which is assigned the value of 5. Two other static variables are made available, they are Thread.MIN_PRIORITY, which is set to 1, and Thread.MAX_PRIORITY, which is set to 10. The getPriority() method can be used to find the current value of the priority of a thread.
Daemon threads
Daemon threads are sometimes called "service" threads that normally run at a low priority and provide a basic service to a program or programs when activity on a machine is reduced. An example of a daemon thread that is continuously running is the garbage collector thread. This thread, provided by the JVM, will scan programs for variables that will never be accessed again and free up their resources back to the system. A thread can set the daemon flag by passing a true boolean value to the setDaemon() method. If a false boolean value is passed, the thread will become a user thread. However, this must occur before the thread has been started.
Scheduling example
The following applet demonstrates the execution of two threads with different priorities. One thread is running at the lowest priority and the other at the highest priority. The threads will count until the faster thread's counter catches up to the slower threads counter.
ScheduleThreads Example and source code
Conclusion
Using threads in Java will enable greater flexibility to programmers looking for that extra edge in their programs. The simplicity of creating, configuring and running threads lets Java programmers devise portable and powerful applets/applications that cannot be made in other third-generation languages. Threads allow any program to perform multiple tasks at once. In an Internet-aware language such as Java, this is a very important tool.