Tomcat manager console

we do discuss about tomcat manager console login :

we do for tomcat server installation, while installing it, i will ask us to give userName/password, though that we can access tomcat manager console.

where as, when we go for tomcat.zip, it won't ask for manager userName/pwd or so.
after unzipping tomcat.zip.
we need to set
JAVA_HOME=%{where our JAVA JDK s/w installed(reside)}%
CATALINA_HOME=%{where our Tomcat s/w unzip/installed(reside)}%
done.
now, when we try to access manager's console, then we need to edit %{CATALINA_HOME}%\conf\tomcat-users.xml

edit tomcat-users.xml :

if you already started tomcat server, shutdown server before edit



and save it.done.

now, run startup.bat
goto http://localhost:8080/
click on 'Tomcat Manager'
it will ask for userName/pwd, provide your specific details.

done.

Unit testing with JUnit and EasyMock

What is a unit test?For the case of this tutorial, we'll define a unit test as a test of a single isolated component in a repeatable way. Let's go thru that one section at a time to get a clearer idea of what goes into a unit test.
"a test". This means to verify something is correct. In order for us to have a valid unit test, we need to actually validate that after a start condition A, an end condition B exists. "...a single isolated component...". This is what separates a unit test from other types of tests. In order for it to be a unit test, it must test something in isolation, aka without dependencies. The reason for this is that we are testing the component itself and not it's interaction with other components (that is an integration test). Finally, although most definitions don't include this piece, "...in a repeatable way" is a very important piece of the definition. It's one thing to run a test that passes. It's quite different to have something you can run in a repeatable manor at any point to see if changes you made effected how the component behaves. For example, if you choose to do some refactoring to improve performance, can you rerun your unit test to verify that you didn't change the behavior of the component.
Setup
I will be using Eclipse 3.3 Europa to do this tutorial. To begin, create a new java project and call it JUnitTutorial. Right click on your new project and select New --> Folder. Name it lib and click Finish. Usually you don't want to package your test code with your regular code, so let's make an additional source directory, test. To do that, right click on your new project and select Properties. Select Java Build Path from the available options. In the Java Build Path window, click Add Folder. From the Add Folder dialog, select Create New Folder, name it test and click Finish. Next we need to add JUnit to our build path. Since it comes with Eclipse, all we need to do is to go to the Libraries tab, click the button Add Library, select JUnit and click Next. Select JUnit 4 and click Finish. Click ok to exit the Preferences window. We will also need to download and add the EasyMock jar files to our project. You can find the jars here. Once you download the zip file (we are using version 2.3 for this tutorial), extract the easymock.jar file and place it in the lib folder you created earlier. In Eclipse, right click on your project and select Properties. On the menu to the left, click Java Build Path and select the Libraries tab. Click the button Add Jar on the right. In the window that pops up, add the easymock.jar and click Ok. Click Ok to close the Properties window. You should now be ready to start your development.
The requirementsIn test driven design, we develop the unit test before the functionality. We write a test that verifies that the class should do X after our call. We prove that the test fails, we then create the component to make the test pass. In this case, we are going to create a service with a method that authenticates a user. Below is a class diagram of the scenario.


The interfacesWe will start our coding by defining two interfaces, LoginService and UserDAO We will implement LoginService, however since in this tutorial UserDAO will be mocked, we won't bother implementing it right now. For LoginService, we have a single method that takes a String userName and String password and returns a boolean (true if the user was found, false if it was not). The interface looks like this:

/**
* Provides authenticated related processing.
*/
public interface LoginService {

/**
* Handles a request to login. Passwords are stored as an MD5 Hash in
* this system. The login service creates a hash based on the paramters
* received and looks up the user. If a user with the same userName and
* password hash are found, true is returned, else false is returned.
*
* @parameter userName
* @parameter password
* @return boolean
*/
boolean login(String userName, String password);
}
The UserDAO interface will look very similar to the LoginService. It will have a single method that takes a userName and hash. The hash is an MD5 hashed version of the password, provided by the above service.

/**
* Provides database access for login related functions
*/
public interface UserDAO {

/**
* Loads a User object for the record that
* is returned with the same userName and password.
*
* @parameter userName
* @parameter password
* @return User
*/
User loadByUsernameAndPassword(String userName, String password);
}
The test caseBefore we begin development, we will develop our test. Tests are structured by grouping methods that perform a test together in a test case. A test case is a class that extends junit.framework.TestCase. So in this case, we will begin by developing the test case for LoginService. To start, in your test directory, create a new class named LoginServiceTest and make it extend junit.framework.TestCase.

The lifecycle of a test execution consists of three main methods:
public void setUp()setUp is executed before each of the test. It is used to perform any setup required before the execution of your test. Your implementation will override the default empty implementation in TestCase.
public void testSomething()testSomething is the actual test method. You may have many of these within a single test case. Each one will be executed by your test runner and all errors will be reported at the end.
public void tearDown()tearDown is executed after each test method. It is used to perform any cleanup required after your tests.

So to begin flushing out our test case, we'll start with the setUp method. In this method, we'll instantiate an instance of the service to be tested. We'll also create our first mock object, UserDAO. You can see the source of our test below.

import junit.framework.TestCase;
import static org.easymock.EasyMock.createStrictMock;
import static org.easymock.EasyMock.expect;
import static org.easymock.EasyMock.replay;
import static org.easymock.EasyMock.verify;
import static org.easymock.EasyMock.eq;
/**
* Test case for LoginService.
*/
public class LoginServiceTest extends TestCase{

private LoginServiceImpl service;
private UserDAO mockDao;

/**
* setUp overrides the default, empty implementation provided by
* JUnit's TestCase. We will use it to instantiate our required
* objects so that we get a clean copy for each test.
*/
@Override
public void setUp() {
service = new LoginServiceImpl();
mockDao = createStrictMock(UserDAO.class);
service.setUserDAO(mockDao);
}
}
EasyMock works by implementing the proxy pattern. When you create a mock object, it creates a proxy object that takes the place of the real object. The proxy object gets it's definition from the interface you pass when creating the mock. We will define what methods are called and their returns from within our test method itself.

When creating a mock object, there are two types, a mock and a strict mock. In either case, our test will tell the mock object what method calls to expect and what to return when they occur. A basic mock will not care about the order of the execution of the methods. A strict mock, on the other hand, is order specific. Your test will fail if the methods are executed out of order on a strict mock. In this example, we will be using a strict mock.

The next step is to create our actual test method (for reference, we will not be implementing a tearDown method for this test case, it won't be needed in this example). In our test method, we want to test the following scenario:



Even with the very basic method we want to test above, there are still a number of different scenarios that require tests. We will start with the "rosy" scenario, passing in two values and getting a user object back. Below is the source of what will be our new test method.

...
/**
* This method will test the "rosy" scenario of passing a valid
* username and password and retrieveing the user. Once the user
* is returned to the service, the service will return true to
* the caller.
*/
public void testRosyScenario() {
User results = new User();
String userName = "testUserName";
String password = "testPassword";
String passwordHash =
"�Ӷ & I7���Ni=.";
expect(mockDao.loadByUsernameAndPassword(eq(userName), eq(passwordHash)))
.andReturn(results);

replay(mockDao);
assertTrue(service.login(userName, password));
verify(mockDao);
}
...
So let's go thru the code above. First, we create the expected result of our DAO call, results. In this case, our method will just check to see if an object was returned, so we don't need to populate our user object with anything, we just need an empty instance. Next we declare the values we will be passing into our service call. The password hash may catch you off guard. It's considered unsafe to store passwords as plain text so our service will generate an MD5 hash of the password and that value is the value that we will pass to our DAO.

The next line is a very important line in our test that alot happens, so let's walk thru it step by step:

expect(mockDao.loadByUsernameAndPassword()This is a call to the static method EasyMock.expect. It tells your mock object to expect the method loadByUsernameAndPassword to be called.
eq(userName), eq(passwordHash)
This code isn't always needed. When EasyMock compares the values passed to the method call, it does and == comparison. Because we are going to create the MD5 hash within our method, an == check will fail, so we have to use one of EasyMock's comparators instead. The eq comparator in this case will compare the contents of the string using it's .equals method. If we were not doing the MD5 hash, this line would be expect(mockDao.loadByUsernameAndPassword(userName, password).andReturn(results);
.andReturn(results);This tells our mock object what to return after this method is called.

The final three lines are the ones that do the testing work. replay(mockDao); tells EasyMock "We're done declaring our expectations. It's now time to run what we told you". assertTrue(service.login(userName, password)); does two things: executes the code to be tested and tests that the result is true. If it is false, the test will fail. Finally, verify(mockDao); tells EasyMock to validate that all of the expected method calls were executed and in the correct order.

So that's it for the test. Now all we have to do is write the code to make it pass. You can find that below.

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;


public class LoginServiceImpl implements LoginService {

private UserDAO userDao;

public void setUserDAO(UserDAO userDao) {
this.userDao = userDao;
}

@Override
public boolean login(String userName, String password) {
boolean valid = false;
try {
String passwordHash = null;
MessageDigest md5 = MessageDigest.getInstance("MD5");
md5.update(password.getBytes());
passwordHash = new String(md5.digest());

User results =
userDao.loadByUsernameAndPassword(userName, passwordHash);
if(results != null) {
valid = true;
}
} catch (NoSuchAlgorithmException ignore) {}

return valid;
}
}
ConclusionSo that is it. I hope this gives you a more in depth view into JUnit and EasyMock. Unit testing is something that once you get used to it, makes you code better, provides you with a safety net for future refactoring and protects you from being burned by API changes. I strongly encourage that you give it a try. Until next time.

Static imports in java 1.5

Static imports allow the static items of another class to be referenced without qualification.

package com;

import static com.StaticImportMe.doStaticImportOnMe;

public class StaticImport {

 /**
  * @param args
  */
 public static void main(String[] args) {
  /**
   * No need to use StaticImportMe.doStaticImportOnMe(args[0]); 
   */
  doStaticImportOnMe(args[0]);
 }

}

Thread - simple note

Thread - a Breaf Note

Threads - Thread Synchronization

* every instance of class Object and its subclass's has a lock
* primitive data type fields (Scalar fields) can only be locked via their enclosing class
* fields cannot be marked as synchronized however they can be declared volatile which orders the way they can be used or you can write synchronized accessor methods
* array objects can be synchronized BUT their elements cannot, nor can their elements be declared volatile
* Class instances are Objects and can be synchronized via static synchronized methods

Synchronized blocks

* allow you to execute synchronized code that locks an object without requiring you to invoke a synchronized method

synchronized( expr ) {
// 'expr' must evaluate to an Object
}

Synchronized methods

* declaring a method as synchronized ie synchronized void f() is equivalent to

void f() { synchronized(this) {
// body of method
}
}

* the synchronized keyword is NOT considered part of a method's signature. IT IS NOT AUTOMATICALLY INHERITED when subclasses override superclass methods
* methods in Interfaces CANNOT be declared synchronized
* constructors CANNOT be declared synchronized however they can contain synchronized blocks
* synchronized methods in subclasses use the same locks as their superclasses
* synchronization of an Inner Class is independent on it's outer class
* a non-static inner class method can lock it's containing class by using a synchronized block

synchronized(OuterClass.this) {
// body
}

Locking

* locking follows a built-in acquire-release protocol controlled by the synchronized keyword
* a lock is acquired on entry to a synchronized method or block and released on exit, even if the exit is the result of an exception
* you cannot forget to release a lock
* locks operate on a per thread basis, not on a per-invocation basis
* Java uses re-entrant locks ie a thread cannot lock on itself

class Reentrant {

public synchronized void a() {
b();
System.out.println("here I am, in a()");
}
public synchronized void b() {
System.out.println("here I am, in b()");
}
}

* in the above code, the synchronized method a(), when executed, obtains a lock on it's own object. It then calls synchronized method b() which also needs to acquire a lock on it's own object
* if Java did not allow a thread to reacquire it's own lock method b() would be unable to proceed until method a() completed and released the lock; and method a() would be unable to complete until method b() completed. Result: deadlock
* as Java does allow reentrant locks, the code compiles and runs without a problem

* the locking protocol is only followed for synchronized methods, it DOES NOT prevent unsynchronized methods from accessing the object
* once a thread releases a lock, another thread may acquire it BUT there is no guarantee as to WHICH thread will acquire the lock next

Class fields and methods

* locking an object does not automatically protect access to static fields
* protecting static fields requires a synchronized static block or method
* static synchronized statements obtain a lock on the Class vs an instance of the class
* a synchronized instance method can obtain a lock on the class

synchronized(ClassName.class) {
// body
}

* the static lock on a class is not related to any other class including it's superclasses
* a lock on a static method has no effect on any instances of that class (JPL pg 185)
* you cannot effectively protect static fields in a superclass by adding a new static synchronized method in a subclass; an explicit block synchronization is the preferred way
* nor should you use synchronized(getClass()); this locks the actual Class which might be different from the class in which the static fields are declared

Inner Classes in Java

As we all know what an inner class is so lets try to know few more rules about Inner Classes.

Inner classes cannot have static members. only static final variables.

Interfaces are never inner.

Static classes are not inner classes.

Inner classes may inherit static members that are not compile-time constants even though they may not declare them.

Nested classes that are not inner classes may declare static members freely, in accordance with the usual rules of the Java programming language. Member interfaces are always implicitly static so they are never considered to be inner classes.A statement or expression occurs in a static context if and only if the innermost method, constructor, instance initializer, static initializer, field initializer, or explicit constructor invocation statement enclosing the statement or expression is a static method, a static initializer, the variable initializer of a static variable, or an explicit constructor invocation statement.

A blank final field of a lexically enclosing class may not be assigned within an inner class.


For Example:

class HasStatic {
static int j = 100;
}

class Outer{

final int z=10;

class Inner extends HasStatic {
static final int x = 3;
static int y = 4;
}

static class Inner2 {
public static int size=130;
}

interface InnerInteface {
public static int size=100;
}
}

public class InnerClassDemo {

public static void main(String[] args) {

Outer outer=new Outer();
System.out.println(outer.new Inner().y);
System.out.println(outer.new Inner().x);
System.out.println(outer.new Inner().j);

System.out.println(Outer.Inner2.size);

System.out.println(Outer.InnerInteface.size);
}
}

Hence it gives compilation problems as y cannot be used in inner class "Inner".

Also note Method parameter names may not be redeclared as local variables of the method, or as exception parameters of catch clauses in a try statement of the method or constructor. However, a parameter of a method or constructor may be shadowed anywhere inside a class declaration nested within that method or constructor. Such a nested class declaration could declare either a local class or an anonymous class.


For Example:
public class MethodParameterExamples {

public String s="bt";

public void m1(String s) {
s=this.s;
s="uk";

//abstract
class InnerClass extends MethodParameterExamples {

String s="ros";

public void m1() {
System.out.println(super.s=this.s);
}
}

InnerClass innerClass=new InnerClass();
innerClass.s=s;
innerClass.m1();

}

public static void main(String[] args) {

MethodParameterExamples methodParameterExamples=new MethodParameterExamples();
methodParameterExamples.m1("vij");
System.out.println(methodParameterExamples.s);

}

}

Hence Prints the output:
uk
bt

Now coming to Section Nested Inner Classes:

Consider the below program.


class WithDeepNesting {
boolean toBe;

WithDeepNesting(boolean b) { toBe = b;}

class Nested {
boolean theQuestion;

class DeeplyNested {

DeeplyNested(){
theQuestion = toBe || !toBe;
}
}
}

public static void main(String[] args) {

WithDeepNesting withDeepNesting=new WithDeepNesting(true);
WithDeepNesting.Nested nested=withDeepNesting.new Nested();
nested.new DeeplyNested();
System.out.println(nested.theQuestion);

}
}

Please note that Inner classes whose declarations do not occur in a static context may freely refer to the instance variables of their enclosing class. An instance variable is always defined with respect to an instance. In the case of instance variables of an enclosing class, the instance variable must be defined with respect to an enclosing instance of that class. So, for example, the class Local above has an enclosing instance of class Outer. As a further example:

Here, every instance of WithDeepNesting.Nested.DeeplyNested has an enclosing instance of class WithDeepNesting.Nested (its immediately enclosing instance) and an enclosing instance of class WithDeepNesting (its 2nd lexically enclosing instance). Hence it prints: true.

Serialization Interview Questions

Q1) What is Serialization?

Ans) Serializable is a marker interface. When an object has to be transferred over a network ( typically through rmi or EJB) or persist the state of an object to a file, the object Class needs to implement Serializable interface. Implementing this interface will allow the object converted into bytestream and transfer over a network.

Q2) What is use of serialVersionUID?

Ans) During object serialization, the default Java serialization mechanism writes the metadata about the object, which includes the class name, field names and types, and superclass. This class definition is stored as a part of the serialized object. This stored metadata enables the deserialization process to reconstitute the objects and map the stream data into the class attributes with the appropriate type
Everytime an object is serialized the java serialization mechanism automatically computes a hash value. ObjectStreamClass's computeSerialVersionUID() method passes the class name, sorted member names, modifiers, and interfaces to the secure hash algorithm (SHA), which returns a hash value.The serialVersionUID is also called suid.
So when the serilaize object is retrieved , the JVM first evaluates the suid of the serialized class and compares the suid value with the one of the object. If the suid values match then the object is said to be compatible with the class and hence it is de-serialized. If not InvalidClassException exception is thrown.

Changes to a serializable class can be compatible or incompatible. Following is the list of changes which are compatible:

* Add fields
* Change a field from static to non-static
* Change a field from transient to non-transient
* Add classes to the object tree

List of incompatible changes:

* Delete fields
* Change class hierarchy
* Change non-static to static
* Change non-transient to transient
* Change type of a primitive field

So, if no suid is present , inspite of making compatible changes, jvm generates new suid thus resulting in an exception if prior release version object is used .
The only way to get rid of the exception is to recompile and deploy the application again.

If we explicitly metion the suid using the statement:

private final static long serialVersionUID =

then if any of the metioned compatible changes are made the class need not to be recompiled. But for incompatible changes there is no other way than to compile again.

Q3) What is the need of Serialization?

Ans) The serialization is used :-

* To send state of one or more object’s state over the network through a socket.
* To save the state of an object in a file.
* An object’s state needs to be manipulated as a stream of bytes.

Q4) Other than Serialization what are the different approach to make object Serializable?

Ans) Besides the Serializable interface, at least three alternate approaches can serialize Java objects:

1)For object serialization, instead of implementing the Serializable interface, a developer can implement the Externalizable interface, which extends Serializable. By implementing Externalizable, a developer is responsible for implementing the writeExternal() and readExternal() methods. As a result, a developer has sole control over reading and writing the serialized objects.
2)XML serialization is an often-used approach for data interchange. This approach lags runtime performance when compared with Java serialization, both in terms of the size of the object and the processing time. With a speedier XML parser, the performance gap with respect to the processing time narrows. Nonetheless, XML serialization provides a more malleable solution when faced with changes in the serializable object.
3)Finally, consider a "roll-your-own" serialization approach. You can write an object's content directly via either the ObjectOutputStream or the DataOutputStream. While this approach is more involved in its initial implementation, it offers the greatest flexibility and extensibility. In addition, this approach provides a performance advantage over Java serialization.

Q5) Do we need to implement any method of Serializable interface to make an object serializable?

Ans) No. Serializable is a Marker Interface. It does not have any methods.

Q6) What happens if the object to be serialized includes the references to other serializable objects?

Ans) If the object to be serialized includes the references to other objects whose class implements serializable then all those object’s state also will be saved as the part of the serialized state of the object in question. The whole object graph of the object to be serialized will be saved during serialization automatically provided all the objects included in the object’s graph are serializable.

Q7) What happens if an object is serializable but it includes a reference to a non-serializable object?

Ans- If you try to serialize an object of a class which implements serializable, but the object includes a reference to an non-serializable class then a ‘NotSerializableException’ will be thrown at runtime.

e.g.

public class NonSerial {
//This is a non-serializable class
}

public class MyClass implements Serializable{
private static final long serialVersionUID = 1L;
private NonSerial nonSerial;
MyClass(NonSerial nonSerial){
this.nonSerial = nonSerial;
}
public static void main(String [] args) {
NonSerial nonSer = new NonSerial();
MyClass c = new MyClass(nonSer);
try {
FileOutputStream fs = new FileOutputStream("test1.ser");
ObjectOutputStream os = new ObjectOutputStream(fs);
os.writeObject(c);
os.close();
} catch (Exception e) { e.printStackTrace(); }
try {
FileInputStream fis = new FileInputStream("test1.ser");
ObjectInputStream ois = new ObjectInputStream(fis);
c = (MyClass) ois.readObject();
ois.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}

On execution of above code following exception will be thrown –
java.io.NotSerializableException: NonSerial
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java)

Q8) Are the static variables saved as the part of serialization?

Ans) No. The static variables belong to the class and not to an object they are not the part of the state of the object so they are not saved as the part of serialized object.

Q9) What is a transient variable?

Ans) These variables are not included in the process of serialization and are not the part of the object’s serialized state.

Q10) What will be the value of transient variable after de-serialization?

Ans) It’s default value.
e.g. if the transient variable in question is an int, it’s value after deserialization will be zero.

public class TestTransientVal implements Serializable{

private static final long serialVersionUID = -22L;
private String name;
transient private int age;
TestTransientVal(int age, String name) {
this.age = age;
this.name = name;
}

public static void main(String [] args) {
TestTransientVal c = new TestTransientVal(1,"ONE");
System.out.println("Before serialization: - " + c.name + " "+ c.age);
try {
FileOutputStream fs = new FileOutputStream("testTransients.ser");
ObjectOutputStream os = new ObjectOutputStream(fs);
os.writeObject(c);
os.close();
} catch (Exception e) { e.printStackTrace(); }


try {
FileInputStream fis = new FileInputStream("testTransients.ser");
ObjectInputStream ois = new ObjectInputStream(fis);
c = (TestTransientVal) ois.readObject();
ois.close();
} catch (Exception e) { e.printStackTrace(); }
System.out.println("After de-serialization:- " + c.name + " "+ c.age);
}

}

Result of executing above piece of code –
Before serialization: - Value of non-transient variable ONE Value of transient variable 1
After de-serialization:- Value of non-transient variable ONE Value of transient variable 0

Explanation –
The transient variable is not saved as the part of the state of the serailized variable, it’s value after de-serialization is it’s default value.

Q11) Does the order in which the value of the transient variables and the state of the object using the defaultWriteObject() method are saved during serialization matter?

Ans) Yes. As while restoring the object’s state the transient variables and the serializable variables that are stored must be restored in the same order in which they were saved.

Q12) How can one customize the Serialization process? or What is the purpose of implementing the writeObject() and readObject() method?

Ans) When you want to store the transient variables state as a part of the serialized object at the time of serialization the class must implement the following methods –
private void wrtiteObject(ObjectOutputStream outStream)
{
//code to save the transient variables state as a part of serialized object
}

private void readObject(ObjectInputStream inStream)
{
//code to read the transient variables state and assign it to the de-serialized object
}

e.g.

public class TestCustomizedSerialization implements Serializable{

private static final long serialVersionUID =-22L;
private String noOfSerVar;
transient private int noOfTranVar;

TestCustomizedSerialization(int noOfTranVar, String noOfSerVar) {
this.noOfTranVar = noOfTranVar;
this.noOfSerVar = noOfSerVar;
}

private void writeObject(ObjectOutputStream os) {

try {
os.defaultWriteObject();
os.writeInt(noOfTranVar);
} catch (Exception e) { e.printStackTrace(); }
}

private void readObject(ObjectInputStream is) {
try {
is.defaultReadObject();
int noOfTransients = (is.readInt());
} catch (Exception e) {
e.printStackTrace(); }
}

public int getNoOfTranVar() {
return noOfTranVar;
}

}

The value of transient variable ‘noOfTranVar’ is saved as part of the serialized object manually by implementing writeObject() and restored by implementing readObject().
The normal serializable variables are saved and restored by calling defaultWriteObject() and defaultReadObject()respectively. These methods perform the normal serialization and de-sirialization process for the object to be saved or restored respectively.

Q13) If a class is serializable but its superclass in not , what will be the state of the instance variables inherited from super class after deserialization?

Ans) The values of the instance variables inherited from superclass will be reset to the values they were given during the original construction of the object as the non-serializable super-class constructor will run.
E.g.

public class ParentNonSerializable {
int noOfWheels;

ParentNonSerializable(){
this.noOfWheels = 4;
}

}

public class ChildSerializable extends ParentNonSerializable implements Serializable {

private static final long serialVersionUID = 1L;
String color;

ChildSerializable() {
this.noOfWheels = 8;
this.color = "blue";
}
}

public class SubSerialSuperNotSerial {

public static void main(String [] args) {

ChildSerializable c = new ChildSerializable();
System.out.println("Before : - " + c.noOfWheels + " "+ c.color);
try {
FileOutputStream fs = new FileOutputStream("superNotSerail.ser");
ObjectOutputStream os = new ObjectOutputStream(fs);
os.writeObject(c);
os.close();
} catch (Exception e) { e.printStackTrace(); }

try {
FileInputStream fis = new FileInputStream("superNotSerail.ser");
ObjectInputStream ois = new ObjectInputStream(fis);
c = (ChildSerializable) ois.readObject();
ois.close();
} catch (Exception e) { e.printStackTrace(); }
System.out.println("After :- " + c.noOfWheels + " "+ c.color);
}

}

Result on executing above code –
Before : - 8 blue
After :- 4 blue

The instance variable ‘noOfWheels’ is inherited from superclass which is not serializable. Therefore while restoring it the non-serializable superclass constructor runs and its value is set to 8 and is not same as the value saved during serialization which is 4.

Q14) To serialize an array or a collection all the members of it must be serializable. True /False?

Ans) true.
-------------------------------------------------------
How many methods in the Serializable interface? Which methods of Serializable interface should I implement?

There is no method in the Serializable interface. It’s an empty interface which does not contain any methods. The Serializable interface acts as a marker, telling the object serialization tools that the class is serializable. So we do not implement any methods.

What is the difference between Serializalble and Externalizable interface? How can you control over the serialization process i.e. how can you customize the seralization process?

When you use Serializable interface, your class is serialized automatically by default. But you can override writeObject() and readObject() two methods to control more complex object serailization process. When you use Externalizable interface, you have a complete control over your class's serialization process. This interface contains two methods namely readExternal and writeExternal. You should implement these methods and write the logic for customizing the serialization process.

How to make a class or a bean serializable? How do I serialize an object to a file?

Or

What interface must an object implement before it can be written to a stream as an object?

An object must implement the Serializable or Externalizable interface before it can be written to a stream as an object. The class whose instances are to be serialized should implement an interface Serializable. Then you pass the instance to the ObjectOutputStream which is connected to a fileoutputstream. This will save the object to a file.

What happens to the object references included in the object?

The serialization mechanism generates an object graph for serialization. Thus it determines whether the included object references are serializable or not. This is a recursive process. Thus when an object is serialized, all the included objects are also serialized alongwith the original object.

What is serialization?

The serialization is a kind of mechanism that makes a class or a bean persistent by having its properties or fields and state information saved and restored to and from storage. That is, it is a mechanism with which you can save the state of an object by converting it to a byte stream.

Common Usage of serialization.

Whenever an object is to be sent over the network or saved in a file, objects are serialized.

What happens to the static fields of a class during serialization?

There are three exceptions in which serialization doesn’t necessarily read and write to the stream. These are
1. Serialization ignores static fields, because they are not part of any particular state.
2. Base class fields are only handled if the base class itself is serializable.
3. Transient fields.

What one should take care of while serializing the object?

One should make sure that all the included objects are also serializable. If any of the objects is not serializable then it throws a NotSerializableException.

What is a transient variable?

Or

Explain the usage of the keyword transient?

Or

What are Transient and Volatile Modifiers

A transient variable is a variable that may not be serialized i.e. the value of the variable can’t be written to the stream in a Serializable class. If you don't want some field to be serialized, you can mark that field transient or static. In such a case when the class is retrieved from the ObjectStream the value of the variable is null.

Volatile modifier applies to variables only and it tells the compiler that the variable modified by volatile can be changed unexpectedly by other parts of the program.

What is Serialization and deserialization?

Serialization is the process of writing the state of an object to a byte stream. Deserialization is the process of restoring these objects.

What is Externalizable?

Externalizable is an interface which contains two methods readExternal and writeExternal. These methods give you a control over the serialization mechanism. Thus if your class implements this interface, you can customize the serialization process by implementing these methods.



If you think that an important java interview question is missing or some answers are wrong in the site please contribute it to sriniappl@gmail.com