* java -Xms <initial size> -Xmx <maximum size> program java -Xms64m -Xmx128m program * Runtime.totalMemory()-Runtime.freeMemory() * Runtime.getRuntime().addShutdownHook(Thread hook).

* Collections.synchronizedList(List list) * HashMap permits null values and only one null key, while Hashtable doesn't all ow key or value as null. * HashSet permits the null element * Comparator comp = Collections.reverseOrder(); * Collections.sort(list, String.CASE_INSENSITIVE_ORDER); * Collections.unmodifiableList(list). * If the start() method is not invoked and the run() method is directly called o n the Thread instance, the code inside the run() method will not run in a separa te new thread but it will start running in the existing thread. * When a synch non static method is called a lock is obtained on the object. Whe n a synch static method is called a lock is obtained on the class and not on the object * In a multi-threaded application each thread will have hare the same heap. This is why care should be taken in oncurrent access issues in the heap space. The stack is will have its own stack) but the heap is not threadsafe hronisation through your code. its own stack but will s your code to avoid any c threadsafe (each thread unless guarded with sync

* strong reference : Normal reference java.lang.ref package defines three other types of references phantom references

soft, weak, and

soft : can be used to implement a cache. weak : used to implement weak maps. phantom : used to reference objects that have been marked for garbage collecti on and have been finalized, but have not yet been reclaimed * The static synchronized methods of the same class always block each other as o nly one lock per class exists. So no two static synchronized methods can execute at the same time. * Can we create a marker interface? A marker or tagging interface is an interphase with no methods. It can be create d by ANYBODY. the purpose of these interfaces is to create a special type of Obj ect, in such a way that you are restricting the classes that can be cast to it w ithout placing ANY restrictions on the exported methods that must be provided. I t mostly indicates that a class should or should not be considered an acceptable class for a certain operation. Some examples are:

Serializable: This is used to indicate that an object may be serialized for pers istance purposes. It has no methods. The writeObject and readObject methods are actually not part of the interface, but rather part of the serialization process , and help determine how to serialize an object. hence, when using a design tool (like jBuilder), when you implement serializable, it automatically creates writ eObject and readObject -- But they are not necessary. Cloneable: Every Object has a method clone(). But in order to call that method, a class must be marked as Cloneable. Thus, it is just another marking interface. Here's an example where you could create youre own tagging interface: let's say you were modeling a department store. You have objects that represent all of the merchendise you can sell. Now, you have an initiative in the store th at you will sell at least 70% American Made merchendise. Then you could create t he interface public interface AmericanMade {} and implement that on every object you sell that is made in America. Now, a cust omer come and wants to purchase only American Made products, so you show him a r evised catalogue, like this: for (Product product : allProducts) { if (product instanceof AmericanMade) { newList.add(product); } }

See, the whole point is that it creates a new type of merchendise, the AmericanM ade, that can be distinguished from others, whether the product is Toilet Paper, T-Shirts, Motor Oil, or Golf Clubs. It does not define any properties or method s, though, because there is likely no difference between an american made golf c lub and an English golf club, except that buying one helps support the American economy, and the other hleps support the English economy. * Everytime an object is serialized the java serialization mechanism automatical ly computes a hash value. ObjectStreamClass's computeSerialVersionUID() method p asses the class name, sorted member names, modifiers, and interfaces to the secu re hash algorithm (SHA), which returns a hash value.The serialVersionUID is also called suid. So when the serilaize object is retrieved , the JVM first evaluates the suid of the serialized class and compares the suid value with the one of the object. If the suid values match then the object is said to be compatible with the class an d hence it is de-serialized. If not InvalidClassException exception is thrown. * By implementing Externalizable, a developer is responsible for implementing th e writeExternal() and readExternal() methods. As a result, a developer has sole control over reading and writing the serialized objects * When you want to store the transient variables state as a part of the serializ ed object at the time of serialization the class must implement the following me thods private void wrtiteObject(ObjectOutputStream outStream) { //code to save the transient variables state as a part of serialized object

} private void readObject(ObjectInputStream inStream) { //code to read the transient variables state and assign it to the de-serialized object } * Immutable class is a class which once created, it s contents can not be changed. Immutable objects are the objects whose state can not be changed once construct ed. e.g. String class public final class FinalPersonClass { private final String name; private final int age; public FinalPersonClass(final String name, final int age) { super(); this.name = name; this.age = age; } public int getAge() { return age; } public String getName() { return name; } } * using System.gc() or Runtime.getRuntime().gc() * The three attribute scopes context, request and session are handled by the Ser vletContext, ServletRequest and HttpSession interfaces. Common methods are Object getAttribute(String name), setAttribute(String name, Object value), removeAttribute(String name), enumeration getAttributeNames(). Context scope isn t thread-safe. Everyone in the app has access to context attributes. To make context attributes thread-safe we need to lock on the context. E.g. synchronized(getServeltContext()) { // here you can set or get the context attributes. } * Session scope isn t thread-safe. This is because the client could open a new br owser window. So, the container can still use the same session for a client, ev en though it s coming from a different instance of the browser. So, Session attri butes are not thread-safe. So, we need to synchronize to make it thread-safe. E.g. synchronized(session) { session.set or session.get in the block } Only Request attributes and local variables are thread-safe. * Instance variables aren t thread-safe. This is because multiple clients making requests on that servlet, that means multiple threads running that servlet code. And all threads have access to the servlet s instance variables, so instance var iables aren t thread-safe. But this instance variables would be thread-safe if we implemented SingleThreadModel. * Getting a Request Dispatcher from a ServletContext : E.g. RequestDispatcher view = getServletContext().getRequestDispatcher( /result.j

sp ); In this you cannot specify a path relative to the current resource. That means you must start the path with a forward slash * If you do encode your URLs, the Container will first attempt to use cookies fo r session management, and fall back to URL rewriting only if the cookie approach fails. E.g. HttpSession session = request.getSession(); out.println( <a href=\ + response.e ncodeURL( /Beer.do ) + \ > Click me</a> ); it means add the extra session ID info to this URL. * URL rewriting works with sendRedirect(). If we have a scenario in which you want to redirect the request to a different URL, but you still want to use a session. There s a special URL encoding method just for that: response.encodeRedirectURL( / BeerTest.do ); * Only HttpSession objects (and their attributes) move from one VM to anot her. There is one ServletContext per VM. There is one ServletConfig per serlve t, per VM. But there is only one HttpSession object for a given session ID per web app, regardless of how many VM s the app is distributed across. * Scriptlet: <% %> Directive: <%@ %> Expression: <%= %>. * All scriptlet and expression code lands in a service method. That means variables declared in a scriptlet are always Local variables

* Anything that is declared between the <%! %> tag is added to the class outside the service method. That means you can declare both static and instance variab les and methods.

* <jsp:useBean id= person type= foo.person class= foo.Employee scope= page > in the gener d servlet it creates as person = new foo.Employee(); So, If type is used without class, the bean must already exist. If clas s is used (with or without type) the class must NOT be abstract, and must have a public no-arg constructor * The include directive happens at translation time and <jsp:include> happens at runtime. * With the <jsp:forward> the buffer is cleared before the forward happends is th rown out.