Difference between JSP include directive and JSP include action

09/05/2008

<%@ include file=filename %> is the JSP include directive. At JSP page translation time, the content of the file given in the include directive is pasted as it is, in the place where the JSP include directive is used. Then the source JSP page is converted into a java servlet class. The included file can be a static resource or a JSP page. Generally JSP include directive is used to include header banners and footers. The JSP compilation procedure is that, the source JSP page gets compiled only if that page has changed. If there is a change in the included JSP file, the source JSP file will not be compiled and therefore the modification will not get reflected in the output.

<jsp:include page=relativeURL /> is the JSP include action element. The jsp:include action element is like a function call. At runtime, the included file will be executed and the result content will be included with the soure JSP page. When the included JSP page is called, both the request and response objects are passed as parameters. If there is a need to pass additional parameters, then jsp:param element can be used. If the resource is static, its content is inserted into the calling JSP file, since there is no processing needed.

How and when to use Singleton classes

April 20th, 2008 Goto commentsLeave a comment

Its a pretty well known pattern, but I want to discuss what a Singleton class is first. In a nutshell, a Singleton class is a class that will only have one instance of the class. In certain cases, we want to make sure that we cannot instantiate multiple copies of the object, so we limit it to just one copy. Instead of having a public constructor for our class, we use a private constructor. Then we use a public method (usually named getInstance()) to make sure there is only one copy. Here is how it looks:

1 public class Singleton { private static final Singleton instance; 2 3 private Singleton(){} 4 5 public static Singleton getInstance() { 6 if (instance == null) 7 instance = new Singleton(); 8 return instance; 9 10 } 11 } As you can see, the constructor is private, so we are unable instantiate it in the normal fashion. What you have to do is call it like this: 1 public Singleton singleton = Singleton.getInstance(); When you do this, the getInstance() method then checks to see if the parameter instance is null. If it is, it will create a new one by calling the private constructor. After that, it just returns it. Of course, if it is not null, it just returns the existing instance of it. This insures that there is only one copy of the object within your program. Of course, this post wouldnt have much meat to it if thats what I left it at. So lets talk about some of the uses of a Singleton class. Also you might at some point as why not just make it static?, which is a common question, so I will go over that about that as well. First, what are the uses of a Singleton?. Singleton classes are normally used for things such as a Factory classes, Builder classes and things like that. A few real world examples include the the SessionFactory class in Hibernate its actually a singleton. Or with log4j, when you call its logger, it uses a singleton class to return it. If anyone has used Cairngorm within Flex/Actionscript 3, its model locator is a Singleton. So why do we want to use singletons in these instances? Lets look at the ModelLocator example within Cairngorm. The model locator is used within Cairngorm to keep the state of data within our Flex application. But the reason why its kept in this one object is that it is used across multiple components. The data in one component is usually important to another component, so everything is managed in one central object. Its quick to realize why we only want one of these in our program. If not, it would be pretty tough to maintain state if other components are affecting data providers that others are using. Another question that usually comes up when it comes to using a Singleton is Why not just use a static class?. Static classes still have many uses and lots of times, people get confused and will use a Singleton as much as possible. One easy rule of thumb you can follow is if it doesnt need to maintain state, you can use a Static class, otherwise you should use a Singleton. So here is a quick list of uses for static classes: Math.pow(double a, double b); Interger.parseInt(String s); Interger.toString(int i); As you can see, the state of these methods dont matter. You just want to use them to perform a simple task for you. But if you coding your application and you are using a central object where state does matter(such as the ModelLocator example), then its best to use a Singleton. The next reason you may want to use a Singleton is if it is a particularly heavy object. If your object is large and takes up a reasonable amount of memory, you probably only one of those objects floating around. This is the case for things like a if you have a factory method that is particularly robust, you

want to make sure that its not going to be instantiated multiple times. A Singleton class will help prevent such the case ever happening. The Singleton is a simple and powerful design pattern. Newer programmers may not realize what potential it has and will over look it. Others may love it so much and end of overusing it in the wrong way. Hopefully this article was helpful for you.

public int hashCode()

This method returns the hash code value for the object on which this method is invoked. This method returns the hash code value as an integer and is supported for the benefit of hashing based collection classes such as Hashtable, HashMap, HashSet etc. This method must be overridden in every class that overrides the equalsmethod. This is what the JDK 1.4 API documentation says about the hashCode method of Object classReturns a hash code value for the object. This method is supported for the benefit of hashtables such as those provided by java.util.Hashtable. The general contract of hashCode is:

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application. If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result. It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

As compared to the general contract specified by the equals method, the contract specified by the hashCode method is relatively simple and easy to understand. It simply states two important requirements that must be met while implementing the hashCode method. The third point of the contract, in fact is the elaboration of the second point. Let's understand what this contract really means. 1. Consistency during same execution - Firstly, it states that the hash code returned by the hashCode method must be consistently the same for multiple invocations during the same execution of the application as long as the object is not modified to affect the equals method. 2. Hash Code & Equals relationship - The second requirement of the contract is the hashCode counterpart of the requirement specified by the equalsmethod. It simply emphasizes the same relationship - equal objects must produce the same hash code. However, the third point elaborates that unequal objectsneed not produce distinct hash codes. After reviewing the general contracts of these two methods, it is clear that the relationship between these two methods can be summed up in the following statement Equal objects must produce the same hash code as long as they are equal, however unequal objects need not produce distinct hash codes. The rest of the requirements specified in the contracts of these two methods are

specific to those methods and are not directly related to the relationship between these two methods. Those specific requirements are discussed earlier. This relationship also enforces that whenever you override the equals method, you must override thehashCode method as well. Failing to comply with this requirement usually results in undetermined, undesired behavior of the class when confronted with Java collection classes or any other Java classes.

Correct Implementation Example

The following code exemplifies how all the requirements of equals and hashCode methods should be fulfilled so that the class behaves correctly and consistently with other Java classes. This class implements the equals method in such a way that it only provides equality comparison for the objects of the same class, similar to built-in Java classes like String and other wrapper classes.
1. public class Test 2. { 3. private int num; 4. private String data; 5. 6. public boolean equals(Object obj) 7. { 8. if(this == obj) 9. return true; 10. if((obj == null) || (obj.getClass() != this.getClass())) 11. return false; 12. // object must be Test at this point 13. Test test = (Test)obj; 14. return num == test.num && 15. (data == test.data || (data != null && data.equals(test.data))); 16. } 17. 18. public int hashCode() 19. { 20. int hash = 7; 21. hash = 31 * hash + num; 22. hash = 31 * hash + (null == data ? 0 : data.hashCode()); 23. return hash; 24. } 25. 26. // other methods 27. } Java interface example : In this example i implemented Java shape interface in the circle class .as you will see in the following example ,up-casting for the object "circleshape" . Note :

In interface : o functions are public and abstract o fields are public and final .
Code:

public class Main {

public static void main(String[] args) {

shape circleshape=new circle();

circleshape.Draw(); } }

interface shape { public String baseclass="shape";

public void Draw();

} class circle implements shape {

public void Draw() { System.out.println("Drawing Circle here"); }

JSP Life Cycle explain.

05/05/2008

JSPs life cycle can be grouped into following phases.

1. JSP Page Translation:

A java servlet file is generated from the JSP source file. This is the first step in its tedious multiple phase life cycle. In the translation phase, the container validates the syntactic correctness of the JSP pages and tag files. The container interprets the standard directives and actions, and the custom actions referencing tag libraries used in the page.

2. JSP Page Compilation:

The generated java servlet file is compiled into a java servlet class. Note: The translation of a JSP source page into its implementation class can happen at any time between initial deployment of the JSP page into the JSP container and the receipt and processing of a client request for the target JSP page.

3. Class Loading:
The java servlet class that was compiled from the JSP source is loaded into the container.

4. Execution phase:
In the execution phase the container manages one or more instances of this class in response to requests and other events. The interface JspPage contains jspInit() and jspDestroy(). The JSP specification has provided a special interface HttpJspPage for JSP pages serving HTTP requests and this interface contains _jspService().

5. Initialization:
jspInit() method is called immediately after the instance was created. It is called only once during JSP life cycle.

6. _jspService() execution:
This method is called for every request of this JSP during its life cycle. This is where it serves the purpose of creation. Oops! it has to pass through all the above steps to reach this phase. It passes the request and the response objects. _jspService() cannot be overridden.

7. jspDestroy() execution:
This method is called when this JSP is destroyed. With this call the servlet serves its purpose and submits itself to heaven (garbage collection). This is the end of jsp life cycle. jspInit(), _jspService() and jspDestroy() are called the life cycle methods of the JSP.
1. import java.util.* ; 2. public class H 3. { 4. static HashMap first = new HashMap(); 5. static 6. { 7. first.put("20030120" , new Integer (56)); 8. first.put("20030118" , new Integer (19)); 9. first.put("20030125" , new Integer (25)); 10. first.put("20030122" , new Integer (32)); 11. first.put("20030117" , new Integer (67)); 12. first.put("20030123" , new Integer (34)); 13. first.put("20030124" , new Integer (42)); 14. first.put("20030121" , new Integer (19)); 15. first.put("20030119" , new Integer (98)); 16. } 17. public static void main( String[] args ) 18. { 19. ArrayList as = new ArrayList( first.entrySet() ); 20. 21. Collections.sort( as , new Comparator() { 22. public int compare( Object o1 , Object o2 ) 23. { 24. Map.Entry e1 = (Map.Entry)o1 ; 25. Map.Entry e2 = (Map.Entry)o2 ; 26. Integer first = (Integer)e1.getValue(); 27. Integer second = (Integer)e2.getValue(); 28. return first.compareTo( second ); 29. } 30. }); 31. 32. Iterator i = as.iterator(); 33. while ( i.hasNext() ) 34. { 35. System.out.println( (Map.Entry)i.next() ); 36. } 37. } 38. }