Check if this is correct:

1) All text content must be between a start and an end tag
2) The document must have 1 root element
3) every start tag must have a matching end tag

The directory structure of a web application consists of two parts.
A private directory called WEB-INF
A public resource directory which contains public resource folder.

WEB-INF folder consists of
1. web.xml
2. classes directory
3. lib directory

The javax.servlet.Servlet interface defines the three methods known as life-cycle method.
public void init(ServletConfig config) throws ServletException
public void service( ServletRequest req, ServletResponse res) throws ServletException, IOException
public void destroy()
First the servlet is constructed, then initialized wih the init() method.
Any request from client are handled initially by the service() method before delegating to the doXxx() methods in the case of HttpServlet.

The servlet is removed from service, destroyed with the destroy() methid, then garbaged collected and finalized

init() This method is called by the servlet container to indicate to the servlet
that it must initialize itself and get ready for service. The container
passes an object of type ServletConfig as a parameter.

service() This method is called by the servlet container for each request from the
client to allow the servlet to respond to the request.

destroy() This method is called by the servlet container to indicate to the servlet
that it must clean up itself, release any required resources, and get ready
to go out of service.

getServletConfig() Returns information about the servlet, such as a parameter to the
init() method.

getServletInfo() The implementation class must return information about the servlet,
such as the author, the version, and copyright information

The wait() method lets a thread to be added to a waiting pool, unless it is invoked again to run
The notify() method is used to send a signal to one and only one of the threads that are waiting in that same object's waiting pool.
The notify() method can NOT specify which waiting thread to notify.
The method notifyAll() works in the same way as notify(), only it sends the signal to all of the threads waiting on the object.
All three methods—wait(), notify(), and notifyAll()—must be called from within a synchronized context! A thread invokes wait() or notify() on a particular object, and the thread must currently hold the lock on that object.

synchronized methods prevent more than one thread from accessing an object's critical method code simultaneously.
You can use the synchronized keyword as a method modifier, or to start a synchronized block of code.
To synchronize a block of code (in other words, a scope smaller than the whole method), you must specify an argument that is the object whose lock you want to synchronize on.
While only one thread can be accessing synchronized code of a particular instance, multiple threads can still access the same object's unsynchronized code.
When a thread goes to sleep, its locks will be unavailable to other threads.
static methods can be synchronized, using the lock from the java.lang.Class instance representing that class.

Sleeping is used to delay execution for a period of time, and no locks are released when a thread goes to sleep.
A sleeping thread is guaranteed to sleep for at least the time specified in the argument to the sleep() method (unless it's interrupted), but there is no guarantee as to when the newly awakened thread will actually return to running.
The sleep() method is a static method that sleeps the currently executing thread's state. One thread cannot tell another thread to sleep.
The setPriority() method is used on Thread objects to give threads a priority of between 1 (low) and 10 (high), although priorities are not guaranteed, and not all JVMs recognize 10 distinct priority levels—some levels may be treated as effectively equal.
If not explicitly set, a thread's priority will have the same priority as the priority of the thread that created it.
The yield() method may cause a running thread to back out if there are runnable threads of the same priority. There is no guarantee that this will happen, and there is no guarantee that when the thread backs out there will be a different thread selected to run. A thread might yield and then immediately reenter the running state.
The closest thing to a guarantee is that at any given time, when a thread is running it will usually not have a lower priority than any thread in therunnable state. If a low-priority thread is running when a high-priority thread enters runnable, the JVM will usually preempt the running low-priority thread and put the high-priority thread in.
When one thread calls the join() method of another thread, the currently running thread will wait until the thread it joins with has completed.

Once a new thread is started, it will always enter the runnable state.
The thread scheduler can move a thread back and forth between the runnable state and the running state.
For a typical single-processor machine, only one thread can be running at a time, although many threads may be in the runnable state.
There is no guarantee that the order in which threads were started determines the order in which they'll run.
There's no guarantee that threads will take turns in any fair way. It's up to the thread scheduler, as determined by the particular virtual machine implementation. If you want a guarantee that your threads will take turns regardless of the underlying JVM, you can use the sleep() method. This prevents one thread from hogging the running process while another thread starves. (In most cases, though, yield() works well enough to encourage
your threads to play together nicely.)
A running thread may enter a blocked/waiting state by a wait(), sleep(), or join() call.
A running thread may enter a blocked/waiting state because it can't acquire the lock for a synchronized block of code.
When the sleep or wait is over, or an object's lock becomes available, thethread can only reenter the runnable state. It will go directly from waiting to running (well, for all practical purposes anyway).
A dead thread cannot be started again

Threads can be created by extending Thread and overriding the public void run() method.
Thread objects can also be created by calling the Thread constructor that takes a Runnable argument. The Runnable object is said to be the target of the thread.
You can call start() on a Thread object only once. If start() is called more than once on a Thread object, it will throw a RuntimeException.
It is legal to create many Thread objects using the same Runnable object as the target.
When a Thread object is created, it does not become a thread of execution until its start() method is invoked. When a Thread object exists but hasn't been started, it is in the new state and is not considered alive.

Both of these java.util classes provide
A sort() method. Sort using a Comparator or sort using natural order.
A binarySearch() method. Search a pre-sorted array or List.
Arrays.asList() creates a List from an array and links them together.
Collections.reverse() reverses the order of elements in a List.
Collections.reverseOrder() returns a Comparator that sorts in reverse.
Lists and Sets have a toArray() method to create arrays

Sorting can be in natural order, or via a Comparable or many Comparators.
Implement Comparable using compareTo(); provides only one sort order.
Create many Comparators to sort a class many ways; implement compare().
To be sorted and searched, a List's elements must be comparable.
To be searched, an array or List must first be sorted

ArrayList: Fast iteration and fast random access.
Vector: It's like a slower ArrayList, but it has synchronized methods.
LinkedList: Good for adding elements to the ends, i.e., stacks and queues.
HashSet: Fast access, assures no duplicates, provides no ordering.
LinkedHashSet: No duplicates; iterates by insertion order.
TreeSet: No duplicates; iterates in sorted order.
HashMap: Fastest updates (key/value pairs); allows one null key,many null values.
Hashtable: Like a slower HashMap (as with Vector, due to its synchronized methods). No null values or null keys allowed.
LinkedHashMap: Faster iterations; iterates by insertion order or last accessed;allows one null key, many null values.
TreeMap: A sorted map.
PriorityQueue: A to-do list ordered by the elements' priority.

Common collection activities include adding objects, removing objects, verifying object inclusion, retrieving objects, and iterating.
Three meanings for "collection":
* collection: Represents the data structure in which objects are stored
* Collection: java.util interface from which Set and List extend
* Collections: A class that holds static collection utility methods

Four basic flavors of collections include Lists, Sets, Maps, Queues:
* Lists of things Ordered, duplicates allowed, with an index.
* Sets of things May or may not be ordered and/or sorted; duplicates
not allowed.
* Maps of things with keys May or may not be ordered and/or sorted;duplicate keys are not allowed.
* Queues of things to process Ordered by FIFO or by priority.

Four basic sub-flavors of collections Sorted, Unsorted, Ordered, Unordered.
* Ordered Iterating through a collection in a specific, non-random order.
* Sorted Iterating through a collection in a sorted order.
* Sorting can be alphabetic, numeric, or programmer-defined

* equals(), hashCode(), and toString() are public.
* Override toString() so that System.out.println() or other methods can see something useful, like your object's state.
* Use == to determine if two reference variables refer to the same object.
* Use equals() to determine if two objects are meaningfully equivalent.
* If you don't override equals(), your objects won't be useful hashing keys.
* If you don't override equals(), different objects can't be considered equal.
* Strings and wrappers override equals() and make good hashing keys.
* When overriding equals(), use the instanceof operator to be sure you're evaluating an appropriate class.
* When overriding equals(), compare the objects' significant attributes.
* Highlights of the equals() contract:
Reflexive: x.equals(x) is true.
Symmetric: If x.equals(y) is true, then y.equals(x) must be true.
Transitive: If x.equals(y) is true, and y.equals(z) is true,then z.equals(x) is true.
Consistent: Multiple calls to x.equals(y) will return the same result.
Null: If x is not null, then x.equals(null) is false.
If x.equals(y) is true, then x.hashCode() == y.hashCode() is true.
If you override equals(), override hashCode().

*HashMap, HashSet, Hashtable, LinkedHashMap, & LinkedHashSet use hashing.
* An efficient hashCode() override distributes keys evenly across its buckets.
* An overridden equals() must be at least as precise as its hashCode() mate.
* To reiterate: if two objects are equal, their hashcodes must be equal.
* It's legal for a hashCode() method to return the same value for all instances
(although in practice it's very inefficient).

Highlights of the hashCode() contract:
* Consistent: multiple calls to x.hashCode() return the same integer.
* If x.equals(y) is true, x.hashCode() == y.hashCode() is true.
q If x.equals(y) is false, then x.hashCode() == y.hashCode() can be either true or false, but false will tend to create better efficiency.
* transient variables aren't appropriate for equals() and hashCode().

The classes you need to understand are all in the java.io package; they include: ObjectOutputStream and ObjectInputStream primarily, and FileOutputStream and FileInputStream because you will use them to create the low-level streams that the ObjectXxxStream classes will use.
* A class must implement the Serializable interface before its objects can be
serialized.
* The ObjectOutputStream.writeObject() method serializes objects, and the ObjectInputStream.readObject() method deserializes objects.
* If you mark an instance variable transient, it will not be serialized even thought the rest of the object's state will be.
* You can supplement a class's automatic serialization process by implementing the writeObject() and readObject() methods. If you do this, embedding calls to defaultWriteObject() and defaultReadObject(), respectively, will handle the part of serialization that happens normally.
* If a superclass implements Serializable, then its subclasses do automatically.
* If a superclass doesn't implement Serializable, then when a subclass object is deserialized, the superclass constructor will run.

String objects are immutable, and String reference variables are not.
If you create a new String without assigning it, it will be lost to your program.
If you redirect a String reference to a new String, the old String can be lost.
String methods use zero-based indexes, except for the second argument of substring().
The String class is final—its methods can't be overridden.
When the JVM finds a String literal, it is added to the String literal pool.
Strings have a method: length(), arrays have an attribute named length.
The StringBuffer's API is the same as the new StringBuilder's API, except that StringBuilder's methods are not synchronized for thread safety.
StringBuilder methods should run faster than StringBuffer methods.
All of the following bullets apply to both StringBuffer and StringBuilder:
* They are mutable—they can change without creating a new object.
* StringBuffer methods act on the invoking object, and objects can change without an explicit assignment in the statement.
* StringBuffer equals() is not overridden; it doesn't compare values.
* Remember that chained methods are evaluated from left to right.
* String methods to remember: charAt(), concat(), equalsIgnoreCase(), length(), replace(), substring(), toLowerCase(), toString(), toUpperCase(), and trim().
* Stringbuffer methods to remember: append(), delete(), insert(), reverse(), and toString()

Exceptions come in two flavors: checked and unchecked.

Checked exceptions include all subtypes of Exception, excluding classes that extend RuntimeException.

Checked exceptions are subject to the handle or declare rule; any methodthat might throw a checked exception (including methods that invoke methods that can throw a checked exception) must either declare the exception using throws, or handle the exception with an appropriate try/catch.
Subtypes of Error or RuntimeException are unchecked, so the compiler doesn't enforce the handle or declare rule. You're free to handle them, or to declare them, but the compiler doesn't care one way or the other.
If you use an optional finally block, it will always be invoked, regardless of whether an exception in the corresponding try is thrown or not, and regardless of whether a thrown exception is caught or not.
The only exception to the finally-will-always-be-called rule is that a finally will not be invoked if the JVM shuts down. That could happen if code from the try or catch blocks calls System.exit().
Just because finally is invoked does not mean it will complete. Code in the finally block could itself raise an exception or issue a System.exit().
Uncaught exceptions propagate back through the call stack, starting from the method where the exception is thrown and ending with either the first method that has a corresponding catch for that exception type or a JVM shutdown (which happens if the exception gets to main(), and main() is "ducking" the exception by declaring it).
You can create your own exceptions, normally by extending Exception or one of its subtypes. Your exception will then be considered a checked exception, and the compiler will enforce the handle or declare rule for that exception.
All catch blocks must be ordered from most specific to most general.
If you have a catch clause for both IOException and Exception, you must put the catch for IOException first in your code. Otherwise, the IOException would be caught by catch(Exception e), because a catch argument can catch the specified exception or any of its subtypes! The compiler will stop you from defining catch clauses that can never be reached.
Some exceptions are created by programmers, some by the JVM.


Unchecked exceptions :

• represent defects in the program (bugs) - often invalid arguments passed to a non-private method. To quote from The Java Programming Language, by Gosling, Arnold, and Holmes : "Unchecked runtime exceptions represent conditions that, generally speaking, reflect errors in your program's logic and cannot be reasonably recovered from at run time."
• are subclasses of RuntimeException, and are usually implemented using IllegalArgumentException, NullPointerException, or IllegalStateException
• a method is not obliged to establish a policy for the unchecked exceptions thrown by its implementation (and they almost always do not do so)

• represent invalid conditions in areas outside the immediate control of the program (invalid user input, database problems, network outages, absent files)
• are subclasses of Exception
• a method is obliged to establish a policy for all checked exceptions thrown by its implementation (either pass the checked exception further up the stack, or handle it somehow)

It is illegal to use a try clause without either a catch clause or a finally
clause. A try clause by itself will result in a compiler error. Any catch clauses must
immediately follow the try block. Any finally clause must immediately follow the last
catch clause (or it must immediately follow the try block if there is no catch). It is legal
to omit either the catch clause or the finally clause, but not both

Static initialization blocks run once, when the class is first loaded.
Instance initialization blocks run every time a new instance is created. They run after all super-constructors and before the constructor's code has run.
If multiple init blocks exist in a class, they follow the rules stated above, AND they run in the order in which they appear in the source file

Methods can take primitives and/or object references as arguments.
Method arguments are always copies.
Method arguments are never actual objects (they can be references to objects).
A primitive argument is an unattached copy of the original primitive.
A reference argument is another copy of a reference to the original object

When an array of objects is instantiated, objects within the array are not instantiated automatically, but all the references get the default value of null.
When an array of primitives is instantiated, elements get default values.
Instance variables are always initialized with a default value.
qLocal/automatic/method variables are never given a default value. If you attempt to use one before initializing it, you'll get a compiler error

When creating a new object, e.g., Button b = new Button();, three
things happen:
Make a reference variable named b, of type Button
Create a new Button object
Assign the Button object to the reference variable b

Scope refers to the lifetime of a variable.
There are four basic scopes:
Static variables live basically as long as their class lives.
Instance variables live as long as their object lives.
Local variables live as long as their method is on the stack; however, if their method invokes another method, they are temporarily unavailable.
Block variables (e.g.., in a for or an if) live until the block completes

Local variables (method variables) live on the stack.
Objects and their instance variables live on the heap