Persistence, Concurrency and RTTI

I got a request to write about Java tenets: Persistence, Concurrency and RTTI. My two cents ....

Persistence:
Object persistence (a.k.a Serialization in Java) is ability to read/write state of object on a stream. Persistence is useful/required in situations when object's state needs to be retained/stored across invocation of a program or when an object needs to be synchronized across JVM's. Examples of persistence are:

1. Storing object state to a file - File input and output streams
2. Storing object state to a database
3. Sending/Receiving/Synchronizing object state across JVM - typically over sockets

Quoting -Carting applications generally use Persistence. A Quote object contains items that you wish to purchase from the online portal. Multiple Quote objects taken together make up a Cart object. The 'Save Cart' option actually serializes the entire Cart object into a Blob colum inside a database table. The Cart object can be reloaded from the db at a later instant to view the complete order.

This brings up two important aspects of Persistence:

1. The entire object state is serialized to the stream (except for transient variables). Object's properties can be primitives or references to other Object's. Thus each such object also needs to be serialized. In a nutshell, serializing an object results into serialization of all objects contained in the current object till nth level.
2. Reflections api is used to create a object by reading its state from the stream.

An object can be serialized only if it implements the marker interface 'Serializable'.

Concurrency:
Java supports MultiThreading. A Thread object is a lightweight process and multiple Threads execute concurrently in JVM. This brings up a potential problem of data corruption by simultaneous access via multiple Threads or in other words maintaining sanctity of data being accessed/mutated by various Threads. Use of synchronized keyword, wait() and notify() methods help us in solving the aforementioned issues. I will not go deep into implementation details of wait(), notify() and synchronized as these will be addressed in the Multi Threading blog.

Each object has a monitor associated with it. When a Thread comes across a synchronized method or block during its execution, it obtains the monitor on the object before entering the method or block. Only one Thread can obtain the monitor on an object. Thus in case a second Thread wants to execute another/same synchronized method/block of the same object, then it blocks till the first Thread release the previously obtained monitor.

RTTI (RunTime Type Identification):
RTTI helps us in identifying the object type at runtime as there may be a need to check the object type prior to executing a chunk of business logic. Implementing Polymorphism with interfaces to achieve extensibilty introduces use of base class reference when objects communicate with each other by sending messages. For example, consider the following hierarchy: Animal interface has implmentation classes Wild and Tame which are further extended by Lion, Tiger, Elephant, Deer, Snake, Dog, Cat etc

With appropriate OO design we will introduce api's like getNumberOfLegs in the Animal interface which will be implemented in the concrete derived classes. While passing a list of animals, each of the element in the list will be Animal reference. But what if we wanted to increment a counter for all animals that were Wild? We can add an isWild() api to Animal class and implement it in Wild and Tame classes. This will get automatically inherited into all the subclasses. The basic purpose of introducing Wild and Tame subclasses gets defeated because within Tame, we are implementing isWild() which returns false. Not a good design.

Instead, while iterating over the Animal list, we can use the instanceof operator, which is Java api for RTTI. We can check if the current element is an instance of Wild and then conditionally increment the counter. Having said this, use of instanceof operator is very heavy and affects the performance. A code having number of if .. else if .. else if ... statements involving instanceof operator suggests bad design.