Basics for Beginners in java.

If you are the new for java then you must learn the concept given below. First go through the following example and than you will be able to understand the basic logic the JAVA program .

First program in java..

Class A

{

public static void main(String arg[])

{

System.out.println("java is a very interesting language");

}

}

Logic behind the public method in JAVA

The public keyword is an access specifier, which allows the programmer to control

the visibility of class members. When a class member is preceded by public, then that member may be accessed by code outside the class in which it is declared. (The opposite

of public is private, which prevents a member from being used by code defined outside of its class.) In this case, main( ) must be declared as public, since it must be called by code outside of its class when the program is started.

Logic behind the static keyword in the above code.

The keyword static allows main( ) to be called without having to instantiate a particular instance of the class. This is necessary since main( ) is called by the Java interpreter before any objects are made.

Logic behind the void keyword in the above code.

The keyword void simply tells the compiler that main( ) does not return a value.

Logic behind the void keyword in the above code.

In JAVA , main( ) is the method called when a Java application begins. Be careful that Java is case-sensitive. Thus, Main is different from main. It is important to understand that the Java compiler will compile classes that do not contain a main( ) method. But the Java interpreter has no way to run these classes. So, if you had typed Main instead of main, the compiler would still compile your program. However, the Java interpreter would report an error because it would be unable to find the main( ) method.

Logic behind the String arg[] in the above code.

In main( ), there is only one parameter. String args[ ] declares a parameter named args, which is an array of instances of the class String. (Arrays are collections of similar objects.) Objects of type String store character strings. In this case, args receives any command-line arguments present when the program is executed.

Logic behind the System.out in the above code.

System is a class.

Out is a static object.

Println() is the method of PrintStream class.

System.out refers to the standard output stream.

Access modifiers in JAVA

In JAVA access specifiers are public, private, protected and default. Java also defines a

default access level. protected applies only when inheritance is involved , and by default any class will be public within the package . The other access specifiers are described next.
Let’s begin by defining public and private. When a member of a class is modified
by the public specifier, then that member can be accessed by any other code. When a
member of a class is specified as private, then that member can only be accessed by
other members of its class.
When no access specifier is used, then by default the
member of a class is public within its own package, but cannot be accessed outside of
its package.

DATA STRUCTURE IN JAVA

Collections in Java

• Arrays

Has special language support

• Iterators

Iterator (i)

• Collections (also called containers)

Collection (i)

Set (i)

HashSet (c), TreeSet (c)

List (i),

ArrayList (c), LinkedList (c)

Map (i),

HashMap (c), TreeMap (c)

Array

• Most efficient way to hold references to objects.

• Advantages

An array know the type it holds, i.e., compile-time type checking.

An array know its size, i.e., ask for the length.

An array can hold primitive types directly.

• Disadvantages

An array can only hold one type of objects (including primitives).

Arrays are fixed size.

Array, Example

• Helper class java.util.Arrays

Search and sort: binarySearch(), sort()

Comparison: equals() (many overloaded)

Instantiation: fill() (many overloaded)

Conversion: asList()

class Car{}; // minimal dummy class

Car[] cars1; // null reference

Car[] cars2 = new Car[10]; // null references

for (int i = 0; i <>

cars2[i] = new Car();

// Aggregated initialization

Car[] cars3 = {new Car(), new Car(), new Car(), new Car()};

cars1 = {new Car(), new Car(), new Car()};

Overview of Collection

• A collection is a group of data manipulate as a single object.

Corresponds to a bag.

• Insulate client programs from the implementation.

array, linked list, hash table, balanced binary tree

• Like C++'s Standard Template Library (STL)

• Can grow as necessary.

• Contain only Objects (reference types).

• Heterogeneous.

• Can be made thread safe (concurrent access).

• Can be made not-modifiable.

Collection Interfaces

• Collections are primarily defined through a set of interfaces.

Supported by a set of classes that implement the interfaces

• Interfaces are used of flexibility reasons

Programs that uses an interface is not tightened to a specific

implementation of a collection.

It is easy to change or replace the underlying collection class with

another (more efficient) class that implements the same interface.

Collection Interfaces and Classes

The Iterator Interface

• The idea: Select each element in a collection

Hide the underlying collection

Iterator

hasNext()

-( it's return type is Boolean).

next()

( it will check for next element)

remove()

Collection

isEmpty()

add()

remove()

...

list

• Iterators are fail-fast

Exception thrown if collection is modified externally, i.e., not via the

iterator (multi-threading).

The Iterator Interface, cont.

// an example

public static void main (String[] args){

ArrayList cars = new ArrayList();

for (int i = 0; i <>

cars.add (new Car());

Iterator it = cars.iterator();

while (it.hasNext())

System.out.println ((Car)it.next());

}

// the interface definition

Interface Iterator {

boolean hasNext();

Object next(); // note "one-way" traffic

void remove();

}

The Collection Interface

public interface Collection {

// Basic Operations

int size();

boolean isEmpty();

boolean contains(Object element);

boolean add(Object element); // Optional

boolean remove(Object element); // Optional

Iterator iterator();

// Bulk Operations

boolean containsAll(Collection c);

boolean addAll(Collection c); // Optional

boolean removeAll(Collection c); // Optional

boolean retainAll(Collection c); // Optional

void clear(); // Optional

// Array Operations

Object[] toArray();

Object[] toArray(Object a[]);

}

The Set Interface

• Corresponds to the mathematical definition of a set (no

duplicates are allowed).

• Compared to the Collection interface

Interface is identical.

Every constructor must create a collection without duplicates.

The operation add cannot add an element already in the set.

The method call set1.equals(set2) works at follows

set1 ??set2, and set2 ??set1

Set Idioms

• set1 ??set2

set1.addAll(set2)

• set1 ??set2

set1.retainAll(set2)

• set1 ??set2

set1.removeAll(set2)

HashSet and TreeSet Classes

• HashSet and TreeSet implement the interface Set.

• HashSet

Implemented using a hash table.

No ordering of elements.

add, remove, and contains methods constant time complexity

O(c).

• TreeSet

Implemented using a tree structure.

Guarantees ordering of elements.

add, remove, and contains methods logarithmic time complexity

O(log (n)), where n is the number of elements in the set.

HashSet, Example

import java.util.*;

public class FindDups {

public static void main(String args[]){

Set s = new HashSet();

for (int i = 0; i <>

if (!s.add(args[i]))

System.out.println("Duplicate detected: " +

args[i]);

}

System.out.println(s.size() +

" distinct words detected: " +

s);

}

}

The List Interface

• The List interface corresponds to an order group of elements.

Duplicates are allowed.

• Extensions compared to the Collection interface

Access to elements via indexes, like arrays

add (int, Object), get(int), remove(int),

set(int, Object) (note set = replace bad name for the method)

Search for elements

indexOf(Object), lastIndexOf(Object)

Specialized Iterator, call ListIterator

Extraction of sublist

subList(int fromIndex, int toIndex)

The List Interface, cont.

Further requirements compared to the Collection Interface

• add(Object)adds at the end of the list.

• remove(Object)removes at the start of the list.

• list1.equals(list2)the ordering of the elements is

taken into consideration.

• Extra requirements to the method hashCode.

list1.equals(list2) implies that

list1.hashCode()==list2.hashCode()

The List Interface, cont.

public interface List extends Collection {

// Positional Access

Object get(int index);

Object set(int index, Object element); // Optional

void add(int index, Object element); // Optional

Object remove(int index); // Optional

abstract boolean addAll(int index, Collection c);

// Optional

// Search

int indexOf(Object o);

int lastIndexOf(Object o);

// Iteration

ListIterator listIterator();

ListIterator listIterator(int index);

// Range-view

List subList(int from, int to);

}

ArrayList and LinkedList Classes

• The classes ArrayList and LinkedList implement the

List interface.

• ArrayList is an array based implementation where elements

can be accessed directly via the get and set methods.

Default choice for simple sequence.

• LinkedList is based on a double linked list

Gives better performance on add and remove compared to

ArrayList.

Gives poorer performance on get and set methods compared to

ArrayList.

ArrayList, Example

// [Source: java.sun.com]

import java.util.*;

public class Shuffle {

public static void main(String args[]) {

List l = new ArrayList();

for (int i = 0; i <>

l.add(args[i]);

Collections.shuffle(l, new Random());

System.out.println(l);

}

}

LinkedList, Example

import java.util.*;

public class MyStack {

private LinkedList list = new LinkedList();

public void push(Object o){

list.addFirst(o);

}

public Object top(){

return list.getFirst();

}

public Object pop(){

return list.removeFirst();

}

public static void main(String args[]) {

Car myCar;

MyStack s = new MyStack();

s.push (new Car());

myCar = (Car)s.pop();

}

}

The ListIterator Interface

public interface ListIterator extends Iterator {

boolean hasNext();

Object next();

boolean hasPrevious();

Object previous();

int nextIndex();

int previousIndex();

void remove(); // Optional

void set(Object o); // Optional

void add(Object o); // Optional

}

The Map Interface

• A Map is an object that maps keys to values. Also called an

associative array or a dictionary.

• Methods for adding and deleting

put(Object key, Object value)

remove (Object key)

• Methods for extraction objects

get (Object key)

• Methods to retrieve the keys, the values, and (key, value) pairs

keySet() // returns a Set

values() // returns a Collection,

entrySet() // returns a set

The MAP Interface, cont.

public interface Map {

// Basic Operations

Object put(Object key, Object value);

Object get(Object key);

Object remove(Object key);

boolean containsKey(Object key);

boolean containsValue(Object value);

int size();

boolean isEmpty();

// Bulk Operations

void putAll(Map t);

void clear();

// Collection Views

public Set keySet();

public Collection values();

public Set entrySet();

// Interface for entrySet elements

public interface Entry {

Object getKey();

Object getValue();

Object setValue(Object value);

}

}

HashMap and TreeMap Classes

• The HashMap and HashTree classes implement the Map

interface.

• HashMap

The implementation is based on a hash table.

No ordering on (key, value) pairs.

• TreeMap

The implementation is based on red-black tree structure.

(key, value) pairs are ordered on the key.

HashMap, Example

import java.util.*;

public class Freq {

private static final Integer ONE = new Integer(1);

public static void main(String args[]) {

Map m = new HashMap();

// Initialize frequency table from command line

for (int i=0; i <>

Integer freq = (Integer) m.get(args[i]);

m.put(args[i], (freq==null ? ONE :

new Integer(freq.intValue() + 1)));

}

System.out.println(m.size()+

" distinct words detected:");

System.out.println(m);

}

}

Static Methods on Collections

• Collection

Search and sort: binarySearch(), sort()

Reorganization: reverse(), shuffle()

Wrappings: unModifiableCollection,

synchonizedCollection

Collection Advantages and Disadvantages

Advantages

• Can hold different types of

objects.

• Resizable

Disadvantages

• Must cast to correct type

• Cannot do compile-time type

checking.

Summary

• Array

Holds objects of known type.

Fixed size.

• Collections

Generalization of the array concept.

Set of interfaces defined in Java for storing object.

Multiple types of objects.

Resizable.

• Queue, Stack, Deque classes absent

Use LinkedList.

About inheritance in java.

Inheritance in java – is the inclusion of behavior (i.e. methods) and state (i.e. variables) of a base class in a derived class so
that they are accessible in that derived class. The key benefit of Inheritance is that it provides the formal mechanism for
code reuse. Any shared piece of business logic can be moved from the derived class into the base class as part of
refactoring process to improve maintainability of your code by avoiding code duplication. The existing class is called the
superclass and the derived class is called the subclass. Inheritance can also be defined as the process whereby one
object acquires characteristics from one or more other objects the same way children acquire characteristics from their
parents. There are two types of inheritances:

1. Implementation inheritance (aka class inheritance): You can extend an application’s functionality by reusing
functionality in the parent class by inheriting all or some of the operations already implemented. In Java, you can only
inherit from one superclass. Implementation inheritance promotes reusability but improper use of class inheritance can
cause programming nightmares by breaking encapsulation and making future changes a problem. With implementation
inheritance, the subclass becomes tightly coupled with the superclass. This will make the design fragile because if you
want to change the superclass, you must know all the details of the subclasses to avoid breaking them. So when using
implementation inheritance, make sure that the subclasses depend only on the behavior of the superclass, not on
the actual implementation. For example in the above diagram, the subclasses should only be concerned about the
behavior known as area() but not how it is implemented.

2. Interface inheritance (aka type inheritance): This is also known as subtyping. Interfaces provide a mechanism for
specifying a relationship between otherwise unrelated classes, typically by specifying a set of common methods each
implementing class must contain. Interface inheritance promotes the design concept of program to interfaces not to
implementations. This also reduces the coupling or implementation dependencies between systems. In Java, you can
implement any number of interfaces. This is more flexible than implementation inheritance because it won’t lock you into
specific implementations which make subclasses difficult to maintain. So care should be taken not to break the
implementing classes by modifying the interfaces.
Which one to use? Prefer interface inheritance to implementation inheritance because it promotes the design concept of
coding to an interface and reduces coupling. Interface inheritance can achieve code reuse with the help of object
composition. If you look at Gang of Four (GoF) design patterns, you can see that it favors interface inheritance to
implementation inheritance.

Polymorphism in java.

Polymorphism in java – means the ability of a single variable of a given type to be used to reference objects of
different types, and automatically call the method that is specific to the type of object the variable references. In a
nutshell, polymorphism is a bottom-up method call. The benefit of polymorphism is that it is very easy to add new
classes of derived objects without breaking the calling code (i.e. getTotArea() in the sample code shown
below) that uses the polymorphic classes or interfaces. When you send a message to an object even though you
don’t know what specific type it is, and the right thing happens, that’s called polymorphism. The process used by
object-oriented programming languages to implement polymorphism is called dynamic binding.

DEALING WITH EXCEPTIONS IN JAVA

JAVA EXCEPTIONS
In JAVA, chances are that your program quit and spewed a bunch of mysterious errors to the screen. Those mysterious errors are exceptions. When your program quits, it's because an exception was "thrown." Exceptions can be thrown by the system or thrown by you, and they can be caught as well (catching an exception involves dealing with it so your program doesn't crash. You'll learn more about this later). "An exception was thrown" is the proper JAVA terminology for "an error happened."
Exceptions don't occur, they are thrown. JAVA throws an exception in response to an unusual situation. You can also throw your own exceptions, or catch an exception to gracefully manage errors.
In JAVA an Exception can be defined as "An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions".
The heart of the JAVA exception system is the exception itself. Exceptions in JAVA are actual objects, instances of classes that inherit from the class Throwable. When an exception is thrown, an instance of a Throwable class is created.

Throwable has two subclasses: Error and Exception. Instances of Error are internal errors in the JAVA runtime environment (the virtual machine). These errors are rare and usually fatal; there's not much you can do about them (either to catch them or to throw them yourself), but they exist so that JAVA can use them if it needs to.
The class Exception is more interesting. Subclasses of Exception fall into two general groups:
· Runtime exceptions (subclasses of the class RuntimeException) such as ArrayIndexOutofBounds, SecurityException, or NullPointerException.
· Other exceptions such as EOFException and MalformedURLException.
Runtime exceptions usually occur because of code that isn't very robust. An ArrayIndexOutofBounds exception, for example, should never be thrown if you're properly checking to make sure your code doesn't extend past the end of an array. NullPointerException exceptions won't happen if you don't try to reference the values of a variable that doesn't actually hold an object. If your program is causing runtime exceptions under any circumstances whatsoever, you should be fixing those problems before you even begin to deal with exception management.
The final group of exceptions is the most interesting because these are the exceptions that indicate that something very strange and out of control is happening. EOFExceptions, for example, happen when you're reading from a file and the file ends before you expect it to. MalformedURLExceptions happen when a URL isn't in the right format (perhaps your user typed it wrong). This group includes exceptions that you yourself create to signal unusual cases that may occur in your own programs.
Exceptions are arranged in a hierarchy like other classes, where the Exception superclasses are more general errors, and subclasses are more specific errors. This organization will become more important to you as you deal with exceptions in your own code.
Most of the exception classes are part of the java.lang package (including Throwable, Exception, and RuntimeException). But many of the other packages define other exceptions, and those exceptions are used throughout the class library. For example, the java.io package defines a general exception class called IOException, which is subclassed not only in the java.io package for input and output exceptions (EOFException, FileNotFoundException), but also in the java.net classes for networking exceptions such as MalFormedURLException.

Managing Exceptions In JAVA.
In many cases, the JAVA compiler enforces exception management when you try to use methods that use exceptions; you'll need to deal with those exceptions in your own code or it simply won't compile. In this section you'll learn about that consistency checking and how to use the try, catch, and finally language keywords to deal with exceptions that may or may not occur.
The JAVA compiler enforces exception management when you try to use methods that use exceptions; you'll need to deal with those exceptions in your own code or it simply won't compile. In this section you'll learn about that consistency checking and how to use the try, catch, and finally language keywords to deal with exceptions that may or may not occur.
Exception Consistency Checking
The more you work with the JAVA class libraries, the more likely it is that you'll run into a compiler error (an exception!) similar to this one:
TestProg.java
Exception java.lang.InterruptedException
must be caught or it must be declared in the throws clause
of this method.
What on earth does that mean? In JAVA, a method can indicate the kinds of errors it might possibly throw. For example, methods that read from files might potentially throw IOException errors, so those methods are declared with a special modifier that indicates potential errors. When you use those methods in your own JAVA programs, you have to protect your code against those exceptions. This rule is enforced by the compiler itself, the same way that the compiler checks to make sure that you're using methods with the right number of arguments and that all your variable types match the thing you're assigning to them.
Why is this check in place? By having methods declare the exceptions they throw, and by forcing you to handle those exceptions in some way, the potential for fatal errors in a program occurring because you simply didn't know they could occur is minimized. You no longer have to carefully read the documentation or the code of an object you're going to use to make sure you've dealt with all the potential problems-JAVA does the checking for you. And, on the other side, if you define your methods so that they indicate the exceptions they can throw, then JAVA can tell users of your objects to handle those errors.
Protecting Code and Catching Exceptions
Let's assume that you've been happily coding and during a test compile you ran into that exception message. According to the message, you have to either catch the error or declare that your method throws it. Let's deal with the first case: catching potential exceptions.
To catch an exception, you do two things:
· You protect the code that contains the method that might throw an exception inside a try block.
· You test for and deal with an exception inside a catch block.
What try and catch effectively mean is "try this bit of code that might cause an exception. If it executes okay, go on with the program. If it doesn't, catch the exception and deal with it."
For Example :
try { Thread.sleep(1000) }
catch (InterruptedException e) {}
While this example uses try and catch, it's not a very good use of it. Here, the Thread.sleep() class method could potentially throw an exception of type InterruptedException (for when the thread is interrupted from running). So we've put the call to sleep() inside the try clause to catch that exception if it happens. And inside catch (inside the parentheses), we indicate that we're specifically looking for InterruptedException exceptions. The problem here is that there isn't anything inside the catch clause-in other words, we'll catch the exception if it happens, but then we'll drop it on the floor and pretend we didn't see it. In all but the simplest cases (such as this one, where the exception really doesn't matter), you're going to want to put something inside the braces after catch to try to do something responsible to clean up after the exception happens.
The part of the catch clause inside the parentheses is similar to the parameter list of a method definition; it contains the class of the exception to be caught and a variable name (e is very commonly used). Inside the body of the catch clause, you can then refer to the exception object, for example, to get to the detailed error message contained in the getMessage() method:
catch (InterruptedException e) {
System.out.println("Ooops. Error: " + e.getMessage());
}
Here's another example. Say you have a program that reads from a file. This program most likely uses one of the streams classes . Stream and I/O," but the basic idea here is that you open a connection to a file and then use the read() method to get data from it. What if some strange disk error happens and the read() method can't read anything? What if the file is truncated and has fewer bytes in it than you expected? In either of these instances, the read() method will throw an IOException which, if you didn't catch it, would cause your program to stop executing and possibly crash. By putting your read() method inside a try clause, you can then deal gracefully with that error inside catch to clean up after the error and return to some safe state, to patch things up enough to be able to proceed, or, if all else fails, to save as much of the current program's state as possible and to exit. This example does just that; it tries to read from the file, and catches exceptions if they happen:
try {
while (numbytes <= mybuffer.length) {
myinputstream.read(mybuffer);
numbytes;++
}
} catch (IOException e) {
System.out.println("Ooops, IO Exception. Only read " + numbytes.");
// other cleanup code
}
Here, the "other cleanup code" can be anything you want it to be; perhaps you can go on with the program using the partial information you got from the file, or perhaps you want to put up a dialog saying that the file is corrupt and to let the user try to select another file or do some other operation.
Note that because the Exception classes are organized into hierarchies as other classes are, and because of the rule that you can use a subclass anywhere a superclass is expected, you can catch "groups" of exceptions and handle them with the same catch code. For example, although there are several different types of IOExceptions (EOFException, FileNotFoundException, and so on-see the java.io package for examples), by catching IOException you also catch instances of any subclass of IOException.
What if you do want to catch very different kinds of exceptions that aren't related by inheritance? You can use multiple catch clauses for a given try, like this:
try {
// protected code
} catch (OneKindOfException e) {
...
} catch (AnotherKindOfException e2) {
....
} catch (YetAnotherException e3) {
...
} catch (StilMoreException e4) {
....
}
Note that because the scope of local variables inside catch is the same as the scope of the outer block (the method definition or a loop if you're inside one), you'll have to use different local variables for each individual catch.
Because the first catch clause that matches is executed, you can build chains such as the following:
try {
someReallyExceptionalMethod();
} catch (NullPointerException n) { // a subclass of RuntimeException
. . .
} catch (RuntimeException r) { // a subclass of Exception
. . .
} catch (IOException i) { // a subclass of Exception
. . .
} catch (MyFirstException m) { // our subclass of Exception
. . .
} catch (Exception e) { // a subclass of Throwable
. . .
} catch (Throwable t) {
. . . // Errors, plus anything not caught above are caught here
}
By listing subclasses before their parent classes, the parent catches anything it would normally catch that's also not one of the subclasses above it. By juggling chains like these, you can express almost any combination of tests.
The finally Clause
Suppose there is some action in your code that you absolutely must do, no matter what happens, whether an exception is thrown or not. Usually, this is to free some external resource after acquiring it, to close a file after opening it, or something similar. While you could put that action both inside a catch and outside it, that would be duplicating the same code in two different places. Instead, put one copy of that code inside a special optional part of the try...catch clause, called finally:
SomeFileClass f = new SomeFileClass();
if (f.open("/a/file/name/path")) {
try {
someReallyExceptionalMethod();
{ catch (IOException e) {
// deal with errors
} finally {
f.close();
}
}
The finally clause is actually useful outside exceptions; you can also use it to execute cleanup code after a return, a break, or a continue inside loops. For the latter cases, you can use a try clause with a finally but without a catch clause.
Here's a fairly complex example of how this might work:
int mysteriousState = getContext();
while (true) {
System.out.print("Who ");
try {
System.out.print("is ");
if (mysteriousState == 1)
return;
System.out.print("that ");
if (mysteriousState == 2)
break;
System.out.print("strange ");
if (mysteriousState == 3)
continue;
System.out.print("but kindly ");
if (mysteriousState == 4)
throw new UncaughtException();
System.out.print("not at all ");
} finally {
System.out.print("amusing man?\n");
}
System.out.print("I'd like to meet the man");
}
System.out.print("Please tell me.\n");
Here is the output produced depending on the value of mysteriousState:
1 Who is amusing man? Please tell me.
2 Who is that amusing man? Please tell me.
3 Who is that strange amusing man? Who is that strange ....
4 Who is that strange but kindly amusing man? Please tell me.
5 Who is that strange but kindly not at all amusing man?
I'd like to meet that man. Who is that strange ...
Note
In cases 3 and 5, the output never ends until you quit the program. In 4, an error message generated by the UncaughtException is also printed.
Declaring Methods That Might Throw Exceptions
In the previous example you learned how to deal with methods that might possibly throw exceptions by protecting code and catching any exceptions that occur. The JAVA compiler will check to make sure you've somehow dealt with a method's exceptions-but how did it know which exceptions to tell you about in the first place?
The answer is that the original method indicated in its signature the exceptions that it might possibly throw. You can use this mechanism in your own methods-in fact, it's good style to do so to make sure that other users of your classes are alerted to the errors your methods may come across.
To indicate that a method may possibly throw an exception, you use a special clause in the method definition called throws.
The throws Clause
To indicate that some code in the body of your method may throw an exception, simply add the throws keyword after the signature for the method (before the opening brace) with the name or names of the exception that your method throws:
public boolean myMethod (int x, int y) throws AnException {
...
}
If your method may possibly throw multiple kinds of exceptions, you can put all of them in the throws clause, separated by commas:
public boolean myOtherMethod (int x, int y)
throws AnException, AnotherExeption, AThirdException {
...
}
Note that as with catch you can use a superclass of a group of exceptions to indicate that your method may throw any subclass of that exception:
public void YetAnotherMethod() throws IOException {
...
}
Keep in mind that adding a throws method to your method definition simply means that the method might throw an exception if something goes wrong, not that it actually will. The throws clause simply provides extra information to your method definition about potential exceptions and allows JAVA to make sure that your method is being used correctly by other people.
Think of a method's overall description as a contract between the designer of that method (or class) and the caller of the method (you can be either side of that contract, of course). Usually, the description indicates the types of a method's arguments, what it returns, and the general semantics of what it normally does. Using throws, you add information about the abnormal things it can do as well. This new part of the contract helps to separate and make explicit all the places where exceptional conditions should be handled in your program, and that makes large-scale design easier.
Which Exceptions Should You Throw?
Once you decide to declare that your method might throw an exception, you have to decide which exceptions it might throw (and actually throw them or call a method that will throw them-you'll learn about throwing your own exceptions in the next section). In many instances, this will be apparent from the operation of the method itself. Perhaps you're creating and throwing your own exceptions, in which case you'll know exactly which exceptions to throw.
You don't really have to list all the possible exceptions that your method could throw; some exceptions are handled by the runtime itself and are so common (well, not common, but ubiquitous) that you don't have to deal with them. In particular, exceptions of either class Error or RuntimeException (or any of their subclasses) do not have to be listed in your throws clause. They get special treatment because they can occur anywhere within a JAVA program and are usually conditions that you, as the programmer, did not directly cause. One good example is OutOfMemoryError, which can happen anywhere, at any time, and for any number of reasons. These two kinds of exceptions are called implicit exceptions, and you don't have to worry about them.
Implicit exceptions are exceptions that are subclasses of the classes RuntimeException and Error. Implicit exceptions are usually thrown by the JAVA runtime itself. You do not have to declare that your method throws them.
Note
You can, of course, choose to list these errors and runtime exceptions in your throws clause if you like, but the callers of your methods will not be forced to handle them; only non-runtime exceptions must be handled.
All other exceptions are called explicit exceptions and are potential candidates of a throws clause in your method.
Passing On Exceptions
In addition to declaring methods that throw exceptions, there's one other instance in which your method definition may include a throws clause. In this case, you want to use a method that throws an exception, but you don't want to catch that exception or deal with it. In many cases, it might make more sense for the method that calls your method to deal with that exception rather than for you to deal with it. There's nothing wrong with this; it's a fairly common occurrence that you won't actually deal with an exception, but will pass it back to the method that calls yours. At any rate, it's a better idea to pass on exceptions to calling methods than to catch them and ignore them.
Rather than using the try and catch clauses in the body of your method, you can declare your method with a throws clause such that it, too, might possibly throw the appropriate exception. Then it's the responsibility of the method that calls your method to deal with that exception. This is the other case that will satisfy the JAVA compiler that you have done something with a given method. Here's another way of implementing an example that reads characters from a stream:
public void readTheFile(String filename) throws IO Exception {
// open the file, init the stream, etc.
while (numbytes <= mybuffer.length) {
myinputstream.read(mybuffer);
numbytes;++
}
This example is similar to the example used previously today; remember that the read() method was declared to throw an IOException, so you had to use try and catch to use it. Once you declare your method to throw an exception, however, you can use other methods that also throw those exceptions inside the body of this method, without needing to protect the code or catch the exception.
Note
You can, of course, deal with other exceptions using try and catch in the body of your method in addition to passing on the exceptions you listed in the throws clause. You can also both deal with the exception in some way and then re-throw it so that your method's calling method has to deal with it anyhow. You'll learn how to throw methods in the next section.
throws and Inheritance
If your method definition overrides a method in a superclass that includes a throws clause, there are special rules for how your overridden method deals with throws. Unlike with the other parts of the method signature, your new method does not have to have the same set of exceptions listed in the throws clause. Because there's a potential that your new method may deal better with exceptions, rather than just throwing them, your subclass's method can potentially throw fewer types of exceptions than its superclass's method definition, up to and including throwing no exceptions at all. That means that you can have the following two class definitions and things will work just fine:
public class Fruit {
public void ripen() throws RotException {
...
}
}
public class WaxFruit extends Fruit {
public void ripen() {
...
}
}
The converse of this rule is not true; a subclass's method cannot throw more exceptions (either exceptions of different types or more general exception classes) than its superclass's method.

What is class Loader in java, it's functions and importance??

Class loaders offer a very powerful mechanism by which classes can be loaded at runtime. Its power lies in its extensibility, i.e. custom classes needed for the application can be loaded in addition to the basic classes loaded by bootstrap loader. But with such powerful tool comes some security problems as well. Its important for application developers to understand the functioning of classloaders to make their application efficient and and it will also make debugging easy.


One of the main features of java is "Write Once and Run Anywhere". The
Java Virtual Machine (JVM) is responsible for loading and executing the code. For this purpose, it uses the java class loader. The java class loaders are responsible for loading appropriate classes in the JVM at the runtime. In a JVM, each and every class is loaded by some instance of a
java.lang.ClassLoader. The main feature of the classloader is that JVM.
doesn’t need to have any knowledge about the classes that will be loaded at runtime. ClassLoaders support features like hot deployment and run time platform e extensibility. The next section explains how a class loader works.

Class Loader Functioning:

A class file is the smallest unit that gets loaded by the class loader. It contains binary representation of a java class
and contains bytecodes and links to other class files that will be used. Class loader reads this bytecode and creates the instance of
java.lang.Class. When the JVM starts, initially only the class file is loaded and other classes are loaded as and when required by the JVM. In this process, JVM is initially
unaware of what classes will be loaded later on. Lazy loading plays a key role in providing dynamic extensibility to the Java platform.
In lazy loading, dependents are only loaded as they are specifically
requested.

Different class loaders are responsible for loading different classes from different repositories.

1. First the " bootstrap class " loader loads the key classes
2. Next comes the " java extension class "loader. It loads the libraries, which are not part of the core java run time.
3. The ExtClassLoader is responsible for loading all .jar files kept in the java.ext.dirs path.
4. Finally, developer ,
   
   can add his own custom classes needed by the application
   
   .

Figure 1 below explains hierarchy of different class loaders.

Figure 1: Hierarchy of class loaders

The process of loading of a class by a class loader is not standalone process. Its a 3-step process.

1. Loading
2. Linking
3. Initialization

Loading is the process of locating the binary representation of a type and bringing it into the JVM. Linking is the process of taking the type and incorporating it into the runtime state of the JVM so that it can be executed. Initialization is the process of executing the initializers of a type (static initializers for classes; static field initializers for classes and interfaces). Once a class becomes unreachable it is available for garbage collection.

The next section deals with how the requested class is searched and loaded by a class loader

How Class Loader Works:

When a client requests to load a particular class, a check is performed by the class loader to see whether the requested class is already loaded. If the class is already loaded then loaded class is returned and
the request ceases. However if the class is not loaded, then the request is sent to the parent class loader to search for the requested class. This request for search can go up to
the level of bootstrap loader (highest in the hierarchy). If the parent is
successful in finding the class then that class is returned and the
request ceases, but if that does not work out, then the current class
loader has to find the requested class.

Each class loader has a specific location for searching the class. e.g
bootstrap loader searches for folders, zips and jars. The methods that are
invoked to search for and load the requested class are

1. protected Class findClass (String className) throws ClassNotFoundException
2. public class loadClass (String className) throws ClassNotFoundException

Action class of Struts Framework

Struts Action class :

An Action class in the struts application extends Struts 'org.apache.struts.action.Action" Class. Action class acts as wrapper around the business logic and provides an interface to the application's Model layer. It acts as glue between the View and Model layer. It also transfers the data from the view layer to the specific business process layer and finally returns the processed data from business layer to the view layer.

An Action works as an adapter between the contents of an incoming HTTP request and the business logic that corresponds to it. Then the struts controller (ActionServlet) slects an appropriate Action and creates an instance if necessary, and finally calls execute method.

Lost data Recover From Hard Disk...

Data Recovery is just like a way to get back and grab the important information that got lost during a computer crash, virus attack or hard disk failure. Whatever maybe the scale of data to be recovered, it is an important and essential part of any operating system. Data is always precious, whether it is for a single user or for a big corporate house; every one needs the retrieval of their precious lost data.

Lost data recovery is possible due to the way the operating system of Microsoft windows is designed. Whenever you delete a file, windows only removes that file from the file system table and keeps track of all the files on your hard disk. There are often some emergent situations when the data recover becomes very essential. Such type of situations arises in case of critical floods, fires and explosions that lead to the data disaster.

One of the ways to recover the lost data is through the system of file data recovery. In this process it is assumed that the tasks that are done while emptying the recycle bin can be reversed. Generally when a file gets deleted, the attribute of the space from an occupied status to an available status used by the file are changed by the operating system. Files are generally lost during a power failure, a hardware crash or sometimes due to a human mistake. Some of these can be recovered based on the extent of damage and the amount of data lost.

Another way is through data disk recover that most people want to settle for. In case data recovery dos not become possible there can be risk to our business or personal work. There are some data recovery software solutions available and the need is to select the best among it according to number of benefits you derive from software. Such software helps you to restore the files.

Situations for using Interface and Abstract class

Primary Difference between an Interface and an Abstract class.

• an abstract class can have a mix of abstract and non-abstract methods, so some default implementations can be defined in the
abstract base class. An abstract class can also have static methods, static data, private and protected methods, etc. In other words, a
class is a class, so it can contain features inherent to a class. The downside to an abstract base class, is that since their is only single
inheritance in Java, you can only inherit from one class.
• an interface has a very restricted use, namely, to declare a set of public abstract method singatures that a subclass is required to
implement. An interfaces defines a set of type constraints, in the form of type signatures, that impose a requirement on a subclass to
implement the methods of the interface. Since you can inherit multiple interfaces, they are often a very useful mechanism to allow a
class to have different behaviors in different situations of usage by implementing multiple interfaces.
It is usually a good idea to implement an interface when you have any methods that are to be overridden by some
subclass. If you then want some of the methods implemented with default implementations that will be inherited by
a subclass, then create an implementation class for the interface.
interface X {
void f();
int g();
}
class XImpl implements X {
void g() { return -1; } // default implementation for g()
}
class Y extends XImpl implements X {
void f() { ... } // provide implementation for f()
}
Note that when you invoke an abstract method using a reference of the type of an abstract class or an interface, the
method call is dynamically dispatched.
X x = new Y;
x.f(); // dynamically determines which f() to invoke, and calls Y.f(this=(Y)x);

What is object oriented

Object-oriented programming (OOP) is a programming paradigm that uses "objects" and their interactions to design applications and computer programs. Programming techniques may include features such as information hiding, data abstraction, encapsulation, modularity, polymorphism, and inheritance. It was not commonly used in mainstream software application development until the early 1990s. Many modern programming languages now support OOP.

Object-oriented programming can trace its roots to the 1960s. As hardware and software became increasingly complex, quality was often compromised . Researchers studied ways to maintain software quality and developed object-oriented programming in part to address common problems by strongly emphasizing discrete, reusable units of programming logic. The methodology focuses on data rather than processes, with programs composed of self-sufficient modules (objects) each containing all the information needed to manipulate its own data structure. This is in contrast to the existing modular programming which had been dominant for many years that focused on the function of a module, rather than specifically the data, but equally provided for code reuse, and self-sufficient reusable units of programming logic, enabling collaboration through the use of linked modules (/subroutines) . This more conventional approach, which still persists, tends to consider data and behavior separately.
An object-oriented program may thus be viewed as a collection of cooperating objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects and can be viewed as an independent 'machine' with a distinct role or responsibility. The actions (or "operators") on these objects are closely associated with the object. For example, the data structures tend to carry their own operators around with them (or at least "inherit" them from a similar object or class).
The Simula programming language was the first to introduce the concepts underlying object-oriented programming (objects, classes, subclasses, virtual methods, coroutines, garbage collection, and discrete event simulation) as a superset of Algol. Simula was used for physical modeling, such as models to study and improve the movement of ships and their content through cargo ports. Smalltalk was the first programming language to be called "object-oriented".[