Struts1 Vs Struts2

Struts1 Vs Struts2

1.  Servlet Dependency:
Actions in Struts1 have dependencies on the servlet API since the HttpServletRequest and HttpServletResponse objects are passed to the execute method when an Action is invoked but in case of Struts 2, Actions are not container dependent because they are made simple POJOs. In struts 2, the servlet contexts are represented as simple Maps which allows actions to be tested in isolation. Struts 2 Actions can access the original request and response, if required. However, other architectural elements reduce or eliminate
the need to access the HttpServetRequest or HttpServletResponse directly.

2.  Action classes
Programming the abstract classes instead of interfaces is one of design issues of struts1 framework that has been resolved in the struts 2 framework. Struts1 Action classes needs to extend framework dependent abstract base class. But in case of Struts 2 Action class may or may not implement interfaces to enable optional and custom services. In case of Struts 2 , Actions are not container dependent because they are made simple POJOs. Struts 2 provides a base ActionSupport class to implement commonly used interfaces. Albeit, the Action interface is
not required. Any POJO object with an execute signature can be used as an Struts 2 Action object.

3.  Validation

Struts1 and Struts 2 both supports the manual validation via a validate method. Struts1 uses validate method on the ActionForm, or validates through an extension to the Commons Validator. However, Struts 2 supports manual validation via the validate method and the XWork Validation framework. The Xwork Validation Framework supports chaining validation into sub-properties using the validations defined for the
properties class type and the validation context.

4.  Threading Model
In Struts1, Action resources must be thread-safe or synchronized. So Actions are singletons and thread-safe, there should only be one instance of a class to handle all requests for that Action. The singleton strategy places restrictions on what can be done with Struts1 Actions and
requires extra care to develop. However in case of Struts2, Action objects are instantiated for each request, so there are no thread-safety issues. (In practice, servlet containers generate many throw-away objects per request, and one more object does not impose a performance penalty
or impact garbage collection.)

5.  Testability
Testing Struts1 applications are a bit complex. A major hurdle to test Struts1 Actions is that the execute method because it exposes the Servlet API. A third-party extension, Struts TestCase, offers a set of mock object for Struts1. But the Struts 2 Actions can be tested by instantiating the Action, setting properties and invoking methods. Dependency Injection support also makes testing simpler. Actions in struts2 are simple POJOs and are framework independent,  hence testability is quite easy in struts2.

6.  Harvesting Input
Struts1 uses an ActionForm object to capture input. And all ActionForms needs to extend a framework dependent base class. JavaBeans cannot be used as ActionForms, so the developers have to create redundant classes to capture input. However Struts 2 uses Action properties (as input
properties independent of underlying framework) that eliminates the need for a second input object, hence reduces redundancy. Additionally in struts2, Action properties can be accessed from the web page via the taglibs. Struts 2 also supports the ActionForm pattern, as well as POJO form objects and POJO Actions. Even rich object types, including business or domain objects, can be used as input/output objects.

7.  Expression Language
Struts1 integrates with JSTL, so it uses the JSTL-EL. The struts1 EL has basic object graph traversal, but relatively weak collection and indexed property support. Struts 2 can also use JSTL, however it supports a more powerful and flexible expression language called “Object Graph Notation Language” (OGNL).

8.  Binding values into views
In the view section, Struts1 uses the standard JSP mechanism to bind objects (processed from the model section) into the page context to access. However Struts 2 uses a “ValueStack” technology so that the taglibs can access values without coupling your view to the object type it is rendering. The ValueStack strategy allows the reuse of views across a range of types which may have the same property name but different property types.

9.  Type Conversion
Usually, Struts1 ActionForm properties are all Strings. Struts1 uses Commons-Beanutils for type conversion. These type converters are per-class and not configurable per instance. However Struts 2 uses OGNL for type conversion. The framework includes converters for basic and common
object types and primitives.

10.  Control Of Action Execution
Struts1 supports separate Request Processor (lifecycles) for each module, but all the Actions in a module must share the same lifecycle. However Struts 2 supports creating different lifecycles on a per Action basis via Interceptor Stacks. Custom stacks can be created and used with
different Actions as needed.

StringBuffer vs String while concatenation

Java provides the StringBuffer and String classes, and the String class is used to manipulate character strings that cannot be changed. Simply stated, objects of type String are read only and immutable. The StringBuffer class is used to represent characters that can be modified.

The significant performance difference between these two classes is that StringBuffer is faster than String when performing simple concatenations. In String manipulation code, character strings are routinely concatenated. Using the String class, concatenations are typically performed as follows:

     String str = new String ("Stanford  ");      str += "Lost!!"; 

If you were to use StringBuffer to perform the same concatenation, you would need code that looks like this:

     StringBuffer str = new StringBuffer ("Stanford ");      str.append("Lost!!"); 

Developers usually assume that the first example above is more efficient because they think that the second example, which uses the append method for concatenation, is more costly than the first example, which uses the + operator to concatenate two String objects.

The + operator appears innocent, but the code generated produces some surprises. Using a StringBuffer for concatenation can in fact produce code that is significantly faster than using a String. To discover why this is the case, we must examine the generated bytecode from our two examples. The bytecode for the example using String looks like this:

0 new #7  3 dup  4 ldc #2  6 invokespecial #12  9 astore_1 10 new #8  13 dup 14 aload_1 15 invokestatic #23  18 invokespecial #13  21 ldc #1  23 invokevirtual #15  26 invokevirtual #22  29 astore_1 

The bytecode at locations 0 through 9 is executed for the first line of code, namely:

     String str = new String("Stanford "); 

Then, the bytecode at location 10 through 29 is executed for the concatenation:

     str += "Lost!!"; 

Things get interesting here. The bytecode generated for the concatenation creates a StringBuffer object, then invokes its append method: the temporary StringBuffer object is created at location 10, and its append method is called at location 23. Because the String class is immutable, a StringBuffer must be used for concatenation.

After the concatenation is performed on the StringBuffer object, it must be converted back into a String. This is done with the call to the toString method at location 26. This method creates a new String object from the temporary StringBuffer object. The creation of this temporary StringBuffer object and its subsequent conversion back into a String object are very expensive.

In summary, the two lines of code above result in the creation of three objects:

1. A String object at location 0
2. A StringBuffer object at location 10
3. A String object at location 26

Now, let's look at the bytecode generated for the example using StringBuffer:

0 new #8  3 dup 4 ldc #2  6 invokespecial #13  9 astore_1 10 aload_1  11 ldc #1  13 invokevirtual #15  16 pop 

The bytecode at locations 0 to 9 is executed for the first line of code:

     StringBuffer str = new StringBuffer("Stanford "); 

The bytecode at location 10 to 16 is then executed for the concatenation:

     str.append("Lost!!"); 

Notice that, as is the case in the first example, this code invokes the append method of a StringBuffer object. Unlike the first example, however, there is no need to create a temporary StringBuffer and then convert it into a String object. This code creates only one object, the StringBuffer, at location 0.

In conclusion, StringBuffer concatenation is significantly faster than String concatenation. Obviously, StringBuffers should be used in this type of operation when possible. If the functionality of the String class is desired, consider using a StringBuffer for concatenation and then performing one conversion to String.

Accessing Private Methods and Variables in Java

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
//Accessing Private methods using Reflection******************Fields can be also used
//in the same Way*********************************************
public class Test {
 public static void main(String ag[])
 {
  A obj=new A();

  try {
   Class c=obj.getClass();
   Method method=c.getDeclaredMethod("msg", null);
   //System.out.println(method);
   try {
 
    method.setAccessible(true);
    method.invoke(obj,null);//Calling Private method of a class.
 
   } catch (IllegalArgumentException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   } catch (IllegalAccessException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   } catch (InvocationTargetException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
   }
  } catch (SecurityException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  } catch (NoSuchMethodException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }


 }
}
////////////second class************Having Private methods
class A
{
 private void msg()
 {
  System.out.println("In class A of private Mehod");
 }
}


//Hi Guys we can access the private fields of a java class using reflection in the same way.
Thanks
Pankaj Kumar Singh