Overriding both doGet() and doPost() in a Servlet

We can override either doGet() or doPost() or both in a Servlet and based upon whether the request is GET or POST, the corresponding method will be called.

The Servlet would compile and run fine.

Eclipse Shortcuts

Adding JavaDoc comments : Alt  + Shift + J
Close All                            : Ctrl + Shift + W / Ctrl + Shift + F4
Collapse All                       : Ctrl + Shift + Numpad_Divide
Copy                                 : Ctrl + C / Ctrl + Insert
Cut                                    : Ctrl + x / Shift + del
Debug                               : F11 
Delete Line                        : Ctrl+ D
Expand All                        : Ctrl + Numpad_Multiply / Ctrl + Numpad_Add
Find next item                   : Ctrl+K
Fine previous Item            : Ctrl+ Shift + K
Format the selected text    : Ctrl+ Shift + F
Go To Line                       : Ctrl + L
Go to matching bracket     : Ctrl+ Shift + P
New                                 : Ctrl + N
Open Type                       : Ctrl + Shift + T
Open Type Hierarchy       : F4
Organize Imports              : Ctrl + Shift + O
Previous Editor                 : Ctrl + Shift + F6
Previous perspective         : Ctrl + Shift + F8
Previous view                   : Ctrl + Shift + F7
Quick Hierarchy               : Ctrl + T
Quick Outline                   : Ctrl + O
References in Workspace : Ctrl + Shift + G
Rename                            : Alt + Shift + R
Run                                  : Ctrl + F11
Show pkg hierarchy in Breadcrumb : Alt + Shift + B
Step Into                         : F5
Step Over                       : F6
Step Return                    : F7
Terminate Debugging      : Ctrl + F2
Toggle Breakpoint          : Ctrl + Shift + B
Toggle Comment            : Ctrl + Shift + C / Ctrl + 7 / Ctrl + /

Java Program without main method

When JVM finds a class, it first executes the static block and then searches for main method.
So, to avoid the JVM from searching for main method, we can execute the required code (iff possible) in static block and then exit .. before the main method is called.

Below is the code :


/**
* @Author : Pragya Rawal
*
*/
public class NoMain {


static {
System.out.println("I am in static block");
System.exit(0);
}
}

Please note that you would not be able to run this program using Eclispe IDE. You will have to run using command line

javac NoMain.java
java NoMain

you would see the output : "I am in static block"

Implementing one-to-many relationship

One-to-many relation can be implemented by using two tables.. in two ways :

e.g we have a Department table and a Student Table

1. Department :
DeptID -> Primary Key
DeptName
DeptHead

Student :
StudentID -> Primary Key
StudentName
DeptID -> Foreign Key

2. Department :
DeptID -> Primary Key
DeptName
DeptHead

Student :
StudentID -> Composite Primary Key - 1
StudentName
DeptID -> Composite Primary Key - 2

Generics and Unboxing

When using legacy (non-type safe) collections—watch out for unboxing problems! If you declare a non-generic collection, the get() methodALWAYS returns a reference of type java.lang.Object. Remember that unboxing can't convert a plain old Object to a primitive, even if that Object reference points to an Integer (or some other primitive) on the heap. Unboxing converts only from a wrapper class reference (like an Integer or a Long) to a primitive.

Generics exist only till compile time. They do not exist at run time

All your generic code is strictly for the compiler. Through a process called "type erasure," the compiler does all of its verifications on your generic code and then strips the type information out of the class bytecode. At runtime, ALL collection code—both legacy and new Java 5 code you write using generics—looks exactly like the pre-generic version of collections. None of your typing information exists at runtime. In other words, even though you WROTE

List myList = new ArrayList();


By the time the compiler is done with it, the JVM sees what it always saw before Java 5 and generics:

List myList = new ArrayList();

The compiler even inserts the casts for you—the casts you had to do to get things out of a pre-Java 5 collection.

Think of generics as strictly a compile-time protection. The compiler uses generic type information (the in the angle brackets) to make sure that your code doesn't put the wrong things into a collection, and that you do not assign what you get from a collection to the wrong reference type. But NONE of this protection exists at runtime.


This compiler warning isn't very descriptive, but the second note suggests that you recompile with -xlint:unchecked. If you do, you'll get something like this:

javac -Xlint:unchecked TestBadLegacy.java
TestBadLegacy.java:17: warning: [unchecked] unchecked call to
add(E) as a member of the raw type java.util.List
list.add(new String("42"));
^
1 warning

When you compile with the -Xlint:unchecked flag, the compiler shows you exactly which method(s) might be doing something dangerous.

Cloneable Interface

The clone( ) method generates a duplicate copy of the object on which it is called. Only classes that implement the Cloneable interface can be cloned.
The Cloneable interface defines no members. It is used to indicate that a class allows a bitwise copy of an object (that is, a clone) to be made. If you try to call clone( ) on a class that does not implement Cloneable, a CloneNotSupportedException is thrown. When a clone is made, the constructor for the object being cloned is not called. A clone is simply an exact copy of the original.

Cloning is a potentially dangerous action, because it can cause unintended side effects. For example, if the object being cloned contains a reference variable called obRef, then when the clone is made, obRef in the clone will refer to the same object as does obRef in the original. If the clone makes a change to the contents of the object referred to by obRef, then it will be changed for the original object, too. Here is another example. If an object opens an I/O stream and is then cloned, two objects will be capable of operating on the same stream. Further, if one of these objects closes the stream, the other object might still attempt to write to it, causing an error.

Because cloning can cause problems, clone( ) is declared as protected inside Object. This means that it must either be called from within a method defined by the class that implements Cloneable, or it must be explicitly overridden by that class so that it is public.