Serialization is also called as Marker Interface

There are four basic things you must do when you are making a class serializable. They are:

1. Implement the Serializable interface.

2. Make sure that instance-level, locally defined state is serialized properly.

3. Make sure that superclass state is serialized properly.

4. Override equals( ) and hashCode( ).

Let’s look at each of these steps in more detail.
Implement the Serializable Interface

This is by far the easiest of the steps. The Serializable interface is an empty interface; it declares no methods at all. So implementing it amounts to adding “implements Serializable” to your class declaration.

Reasonable people may wonder about the utility of an empty interface. Rather than define an empty interface, and require class definitions to implement it, why not just simply make every object serializable? The main reason not to do this is that there are some classes that don’t have an obvious serialization. Consider, for example, an instance of File. An instance of File represents a file. Suppose, for example, it was created using the following line of code:

File file = new File(“c:\\New Floder\\Temp”);

It’s not at all clear what should be written out when this is serialized. The problem is that the file itself has a different lifecyle than the serialized data. The file might be edited, or deleted entirely, while the serialized information remains unchanged. Or the serialized information might be used to restart the application on another machine, where “C:\\New Floder\\Temp” is the name of an entirely different file.

Another example is provided by the Thread[4] class. A thread represents a flow of execution within a particular JVM. You would not only have to store the stack, and all the local variables, but also all the related locks and threads, and restart all the threads properly when the instance is deserialized.

TIP:   Things get worse when you consider platform dependencies. In general, any class that involves native code is not really a good candidate for serialization.

Make Sure That Instance-Level, Locally Defined State Is Serialized Properly

Class definitions contain variable declarations. The instance-level, locally defined variables (e.g., the nonstatic variables) are the ones that contain the state of a particular instance. For example, in our Money class, we declared one such field:

public class Money extends ValueObject {
private int _cents;
….
}

The serialization mechanism has a nice default behavior–if all the instance-level, locally defined variables have values that are either serializable objects or primitive datatypes, then the serialization mechanism will work without any further effort on our part. For example, our implementations of Account, such as Account_Impl, would present no problems for the default serialization mechanism:

public class Account_Impl extends UnicastRemoteObject implements Account {
private Money _balance;
…
}

While _balance doesn’t have a primitive type, it does refer to an instance of Money, which is a serializable class.

If, however, some of the fields don’t have primitive types, and don’t refer to serializable classes, more work may be necessary. Consider, for example, the implementation of ArrayList from the java.util package. An ArrayList really has only two pieces of state:

public class ArrayList extends AbstractList implements List, Cloneable, java.io.
Serializable {
private Object elementData[];
private int size;
…
}

But hidden in here is a huge problem: ArrayList is a generic container class whose state is stored as an array of objects. While arrays are first-class objects in Java, they aren’t serializable objects. This means that ArrayList can’t just implement the Serializable interface. It has to provide extra information to help the serialization mechanism handle its nonserializable fields. There are three basic solutions to this problem:

* Fields can be declared to be transient.

* The writeObject( )/readObject( ) methods can be implemented.

* serialPersistentFields can be declared.

You can find more information on serialization at 1 and 2

Related Post

• July 21, 2010 -- Explain Briefly about Serialization (0)
• July 21, 2010 -- Using Serialization (0)

Note: When serializing an object to a file, the standard convention in Java is to give the file a .ser extension.

import java.io.*;

public class SerializeDemo
{

public static void main(String [] args)
{

Employee e = new Employee();
e.name = “Ramakrishna”;
e.address = “Hyderabad”;
e.SSN = 11122333;
e.number = 200113;

try
{

FileOutputStream fileOut =
new FileOutputStream(“employee.ser”);
ObjectOutputStream out =
new ObjectOutputStream(fileOut);
out.writeObject(e);
out.close();
fileOut.close();

}catch(IOException i)
{
i.printStackTrace();
}
}
}

The following DeserializeDemo program deserializes the Employee object created in the SerializeDemo program. Study the program and try to determine its output:

import java.io.*;

public class DeserializeDemo
{

public static void main(String [] args)
{

Employee e = null;

try
{
FileInputStream fileIn =
new FileInputStream(“employee.ser”);
ObjectInputStream in = new ObjectInputStream(fileIn);
e = (Employee) in.readObject();
in.close();
fileIn.close();
}catch(IOException i)
{
i.printStackTrace();
return;

}catch(ClassNotFoundException c)
{
System.out.println(.Employee class not found.);
c.printStackTrace();
return;
}

System.out.println(“Deserialized Employee…”);
System.out.println(“Name: ” + e.name);
System.out.println(“Address: ” + e.address);
System.out.println(“SSN: ” + e.SSN);
System.out.println(“Number: ” + e.number);
}
}

This would produce following result:

Deserialized Employee…
Name: Ramakrishna
Address:Hyderabad
SSN: 0
Number:200113

In particular, there are three main uses of serialization:

As a persistence mechanism
If the stream being used is FileOutputStream, then the data will automatically be written to a file.

As a copy mechanism
If the stream being used is ByteArrayOutputStream, then the data will be written to a byte array in memory. This byte array can then be used to create duplicates of the original objects.

As a communication mechanism
If the stream being used comes from a socket, then the data will automatically be sent over the wire to the receiving socket, at which point another program will decide what to do.

The important thing to note is that the use of serialization is independent of the serialization algorithm itself. If we have a serializable class, we can save it to a file or make a copy of it simply by changing the way we use the output of the serialization mechanism.

As you might expect, serialization is implemented using a pair of streams. Even though the code that underlies serialization is quite complex, the way you invoke it is designed to make serialization as transparent as possible to Java developers. To serialize an object, create an instance of ObjectOutputStream and call the writeObject( ) method; to read in a serialized object, create an instance of ObjectInputStream and call the readObject( ) object.

TIP: There are two versions of the serialization protocol currently defined: PROTOCOL_VERSION_1 and PROTOCOL_VERSION_2. If you send serialized data to a 1.1 (or earlier) JVM, you should probably use PROTOCOL_VERSION_1. The most common case of this involves applets. Most applets run in browsers over which the developer has no control. This means, in particular, that the JVM running the applet could be anything, from Java 1.0.2 through the latest JVM. Most servers, on the other hand, are written using JDK1.2.2 or later.[3] If you pass serialized objects between an applet and a server, you should specify the serialization protocol.

Related Post

• July 21, 2010 -- How to Make a Class Serializable (1)
• July 21, 2010 -- Explain Briefly about Serialization (0)

What does it mean for the client to pass an instance of Money to the server? At a minimum, it means that the server is able to call public methods on the instance of Money. One way to do this would be to implicitly make Money into a server as well.[1] For example, imagine that the client sends the following two pieces of information whenever it passes an instance as an argument:

• The type of the instance; in this case, Money.
• A unique identifier for the object (i.e., a logical reference). For example, the address of the instance in memory.

The RMI runtime layer in the server can use this information to construct a stub for the instance of Money, so that whenever the Account server calls a method on what it thinks of as the instance of Money, the method call is relayed over the wire

Attempting to do things this way has three significant drawbacks:

• You can’t access fields on the objects that have been passed as arguments.

Stubs work by implementing an interface. They implement the methods in the interface by simply relaying the method invocation across the network. That is, the stub methods take all their arguments and simply marshall them for transport across the wire. Accessing a public field is really just dereferencing a pointer–there is no method invocation and hence, there isn’t a method call to forward over the wire.

• It can result in unacceptable performance due to network latency.

Even in our simple case, the instance of Account is going to need to call getCents( ) on the instance of Money. This means that a simple call to makeDeposit( ) really involves at least two distinct networked method calls: makeDeposit( ) from the client and getCents( ) from the server.

• It makes the application much more vulnerable to partial failure.

Let’s say that the server is busy and doesn’t get around to handling the request for 30 seconds. If the client crashes in the interim, or if the network goes down, the server cannot process the request at all. Until all data has been requested and sent, the application is particularly vulnerable to partial failures.

This last point is an interesting one. Any time you have an application that requires a long-lasting and durable connection between client and server, you build in a point of failure. The longer the connection needs to last, or the higher the communication bandwidth the connection requires, the more likely the application is to occasionally break down.
TIP: The original design of the Web, with its stateless connections, serves as a good example of a distributed application that can tolerate almost any transient network failure. These three reasons imply that what is really needed is a way to copy objects and send them over the wire. That is, instead of turning arguments into implicit servers, arguments need to be completely copied so that no further network calls are needed to complete the remote method invocation. Put another way, we want the result of makeWithdrawal( ) to involve creating a copy of the instance of Money on the server side. The runtime structure should resemble

The desire to avoid unnecessary network dependencies has two significant consequences:

• Once an object is duplicated, the two objects are completely independent of each other.

Any attempt to keep the copy and the original in sync would involve propagating changes over the network, entirely defeating the reason for making the copy in the first place.

• The copying mechanism must create deep copies.

If the instance of Money references another instance, then copies must be made of both instances. Otherwise, when a method is called on the second object, the call must be relayed across the wire. Moreover, all the copies must be made immediately–we can’t wait until the second object is accessed to make the copy because the original might change in the meantime.

These two consequences have a very important third consequence:

• If an object is sent twice, in separate method calls, two copies of the object will be created.

In addition to arguments to method calls, this holds for objects that are referenced by the arguments. If you pass object A, which has a reference to object C, and in another call you pass object B, which also has a reference to C, you will end up with two distinct copies of C on the receiving side.

Related Post

• July 21, 2010 -- How to Make a Class Serializable (1)
• July 21, 2010 -- Using Serialization (0)

if you need to delete the rows just u need to select that check box and go for the delete button .

You can have this code for using in your application this must be related to the button which you will use in your application

the Code is

function deleteRow() {
try {
var table = document.getElementById(‘myTable’);
//alert(‘table’+table);
var rowCount = table.rows.length;

for(var i=0; i<rowCount; i++) {
var row = table.rows[i];
var chkbox = row.cells[0].childNodes[0];
if(null != chkbox && false == chkbox.checked) {
table.deleteRow(i);
rowCount–;
i–;
}

}
}catch(e) {
alert(e);
}
}

<INPUT type=”button” value=”Delete Row” onclick=”deleteRow()” />

Random Posts

• September 2, 2008 -- Define Session Tracking in HttpServlet (0)
• October 4, 2008 -- What is JTAPI (0)
• June 30, 2008 -- Java Exception Handling Questions (0)
• October 27, 2008 -- Final Variables and Methods (0)
• September 22, 2008 -- What are Command Line Arguments in Java (0)

There are two types of executing the statements in MultiTasking.

Executing several task at a time by the microprocessor is called MultiTasking.

In MultiTasking the processor time is utilized in an optimum way

The 2 type of MultiTasking are as follows.

(i) Process Based MultiTasking :

In this several programs are executed by the Microprocessor using RoundRobin Method.

(ii) Thread Based MultiTasking :

Executing different parts (methods ) of the same program at a time using thread is called Thread Based MultiTasking.

Random Posts

• August 24, 2008 -- Software Architecture of EJB (0)
• September 2, 2008 -- Difference between getCurrentSession() and openSession() (0)
• September 2, 2008 -- Advantage of Cookies over URL (0)
• May 22, 2008 -- Java lang package interview questions (2)
• October 3, 2008 -- Explain Jsp Directives (0)

Related Post

• December 17, 2008 -- When the port number is changed (0)
• March 24, 2009 -- Define HashSet Class (0)
• December 17, 2008 -- Explain Stream Tokenizer (0)
• December 17, 2008 -- What is Abstract Class?Explan (0)
• December 12, 2008 -- URL Connection Class (0)

–> When you write servlets , you override the doGet and doPost methods to provide the processing that’s required. These methods receive the request object and the  response object that are passed to them by the server.

–> After you use the setContentType method of the response object to set the content type of the response that’s returned to the browser, you use the getWriter method  to create a PrintWriter object. Then, you can use the println and print methods of  that object to send HTML back to the browser.

–> The class files for servlets must be stored in the WEB-INF\classes directory of an  application or in a subdirectory that corresponds to a package name.

–> To request a servlet from a URL, you include the word “servlet” after the document root directory in the path. This is followed by the package name, a dot, and the servlet name.

–> You can override the init method of a servlet to initialize its instance variables. These variables are then available to all of the threads that are spawned for the one instance of the servlet.

–> When you code a thread-safe servlet, you prevent two or more users from accessing  the same block of code at the same time.

–> To print debugging data to the server console, you can use the println method of  the System.out or System.err object. An alternative is to use the log methods of the  HttpServlet class to write debugging data to a log file.

Random Posts

• October 16, 2008 -- What the web.xml file can do (1)
• July 12, 2008 -- Hibernate Interview Questions (35)
• August 10, 2008 -- Can we call destroy() method on servlets from service method (0)
• July 7, 2008 -- JMS INTERVIEW QUESTIONS (1)
• August 24, 2008 -- Define implicit objects (1)

–> An instance variable of a servlet belongs to the one instance of the servlet and is shared by any threads that request the servlet.

–> You can initialize an instance variable in the init method.

–> If you don’t want two or more threads to modify an instance variable at the same time, you must synchronize the access to the instance variables.

–> To synchronize access to a block of code, you can use the synchronized keyword and the this keyword.

How to limit the use of code to a single thread at  three different levels. First, you can synchronize a block of code by using the synchronized and this keywords. Second, you can synchronize an entire method. Third, you can use the SingleThreadModel interface to limit the use of  an entire servlet to a single thread. That way, you don’t have to synchronize any  of the code within the servlet.

you must remember that one thread has to  wait while another thread is using a synchronized block of code, a synchronized method, or a single-thread servlet.

Random Posts

• September 30, 2008 -- Define Implicit Variables in JSP (0)
• October 16, 2008 -- Define JSP (2)
• July 24, 2008 -- JSF Important Questions (2)
• August 24, 2008 -- Difference between String and StringBuffer (0)
• October 16, 2008 -- What is Thread Safe Servlet (0)

The synchronized keyword prevents two threads from using the method or modifying the instance variable at the same time. This results in a thread-safe JSP.

First, each JSP is translated into a servlet class.
Second, the servlet class is compiled when the first user requests the JSP.
Third, one instance of the servlet class is instantiated when the first user requests the JSP.
Fourth, each user is treated as a thread by the servlet, and each thread gets its own copy of the local variables of the servlet methods.

When you use the Get method to pass parameters to a JSP, the parameters are displayed in the URL. When you use the Post method, they aren’t. Although the Get method transfers data faster than the Post method, you can’t use the Get method to transfer more than 4K of data.

You use a JSP directive known as a page directive to import classes for use in a JSP.

When you use JSP comments, the comments aren’t compiled or executed. In
contrast, HTML comments are compiled and executed, but the browser doesn’t display them.

You use JSP declarations to declare instance variables and methods for a JSP. To code a thread-safe JSP, you must synchronize access to these instance variables and methods.

When a JSP is first requested, the JSP engine translates the page into a servlet and  compiles it. Then, one instance of the class is instantiated. For each subsequent  request, a new thread is created from this single instance of the servlet class. This means that each requestor gets its own copy of the local variables, but all requestors share the same instance variables.

Within the doGet method, the first two statements perform tasks that are
common to most servlets that return an HTML document. Here, the first statement sets the content type that will be returned to the browser. In this case, the content type is set so that the servlet returns an HTML document, but it’s possible to return other content types. Then, the second statement returns a PrintWriter object that’s used to return data to the browser later on.

The doPost method calls the doGet method, an HTTP request that uses the Post method will actually execute the doGet method of the servlet.

Random Posts

• August 24, 2008 -- Software Architecture of EJB (0)
• August 24, 2008 -- Define business logic and business method (0)
• January 26, 2009 -- Uploading file name or image to DataBase (0)
• September 16, 2008 -- Converting Hibernate with Eclipse Integration (0)
• July 7, 2008 -- Java RMI Interview questions (0)

Random Posts

• February 15, 2009 -- Write a note on EJB frame work (0)
• September 22, 2008 -- Calling a Method in Java (1)
• October 5, 2008 -- GoTo statement in Java (0)
• January 14, 2009 -- Sockets programming in Java for Client/Server (0)
• December 16, 2008 -- Define Array in Java (1)