What is compile time and runtime polymorphism?

Overloading is compile time polymorphism,
because compiler checks the method signatures while compiling itself। (i e: Method names, Argument types, argument creation order, etc...)
Overriding is run time polymorphism।

What are the differences between HashMap and Hashtable?

Both provide key-value access to data. The Hashtable is one of the original collection classes in Java. HashMap is part of the new Collections Framework, added with Java 2, v1.2.
The key difference between the two is that access to the Hashtable is synchronized on the table while access to the HashMap isn't. You can add it, but it isn't there by default.

Another difference is that iterator in the HashMap is fail-safe while the enumerator for the Hashtable isn't. If you change the map while iterating, you'll know.

And, a third difference is that HashMap permits null values in it, while Hashtable doesn't.

StringBuffer versus String

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:

A String object at location 0
A StringBuffer object at location 10
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.

Understanding Class.forName()

Dynamic loading of Java classes at runtime provides tremendous flexibility in the development of enterprise systems. It provides for the basis of "application servers", and allows even simpler, lighter-weight systems to accomplish some of the same ends. Within Java, dynamic loading is typically achieved by calling the forName method on the class java.lang.Class;

Dynamic run-time loading One of Java's strongest features is its ability to dynamically load code given the name of the class to load, without having to know the actual classname until runtime. This allows Java developers to build flexible, dynamic systems that can grow and change without requiring complete recompilation.

This use of dynamic runtime loading is the heart of Java Application Servers like the Java2 Enterprise Edition reference implementation, Enterprise JavaBeans, and the Servlet Specification. In each one of these architectures, at the time the application server is compiled, it knows nothing about the code that will be attached to it. Instead, it simply asks the user for a classname to load, loads the class, creates an instance of the class, and starts making method calls on that instance. (It does so either through Reflection, or by requiring that clients implement a particular interface or class, like GenericServlet in the
Servlet spec, or EJBObject in the EJB spec.)

Use of dynamic run-time loading isn't restricted solely to server-side architectures, however. Web browsers must use it in order to be able to load applets specified by name by a remote web page, as well. RMI uses it to dynamically load stubs and/or skeletons for remote objects, and JNDI and JDBC will use it to load, at runtime, the exact driver necessary (given by the user's appropriate ".properties" file) to perform the work asked. In each case, a ClassLoader is asked to load a class by name that may not have existed within the JVM before this moment.

Can I run a java program without main() method?

The Java launcher starts the main method of the class named on command line. In that sense, it is not possible to run a Java program without a main method. But you could write a launcher of your own that starts some other method. Many frameworks have their own main method and depend on some other predefined protocol to provide control to the user program. Web containers depend on configuration file that determine servlet classes on which process or doGet/doPost methods. In a manner of speaking, these servlets are programs, but there is no main method.

Exception is raised only during Run time, then, why we have three types of exceptions which are exception, runtime exception and error exception?

The runtime in a runtime exception does not refer to the fact that it is thrown at runtime. The exceptions are thrown as part of the program execution, so of course they can be thrown only when the program is executing.
The classification of the exceptions relates to the severity of the cause. Java has an elaborate exception-checking model. A method may declare that it can potentially throw any of the exceptions that it declares in its throws clause. It is responsibility of the calling method catches these exceptions and/or throws them itself. If the calling method throws this exception it too needs to declare it in its throws clause.
The above applies to the checked exceptions. These are the objects (yes, exceptions are objects too) that extend the class Exception, except those that extend RuntimeException. Such checked exceptions can for example be thrown by methods when the calling method does not satisfy one of the preconditions of that method.
The rules of declarations are more lenient for RuntimeExceptions and Error. Methods are neither required to declare them in their throws clause nor are required to catch them. These usually signal an error in program logic or conditions under which abnormal program (or thread) termination is acceptable.

JavaServer Pages for beginners

follow this link
JavaServer Pages for beginners
and learn complete flow of jsp page processing in any web application.