Skip to main content

What are the precautions for implementing Serializable?

In Effective Java Programming Language Guide, Joshua Bloch wrote many thoughts about serialization. Here is a summary of some precautions recommended:
  • If you do not get to the effort to design a custom serialized form, but merely accept the default, the class's private and package instance fields becomes part of its exported API. In this way, it decreases the flexibility to change a class's implementation once it has been released.
  • Serial versions UIDs are automatically generated based on the name of the class, the names of their interfaces, and of all public and protected members. If a change is made to the class but you do not provide a custom serial UID the compatibility will be broken.
  • Serialization is a extralinguistic mechanism, deserialization is a hidden constructor. All the invariants for an object should be checked in the process of deserializing an object, as a constructor would do.
  • Classes design for inheritance should rarely implement serializable. Doing otherwise places a burden into the programmer extending the class.
  • Inner classes should rarely implement Serializable. Their synthetics fields and names are not specified.
  • The default serialization process deals with the physical representation of an object. It also describes the topology of the objects referenced from the object to be serialized. But what is really important to serialize is the logical data of the object.
  • Disadvantages of using the default serialization when the physical representation of an object differs greatly form the logical:
    • It permanently ties the exported API to the internal representation
    • It can consume excessive time or space
    • it can overflows.
  • A stream of bytes to be deserialized could have been tampered with to change the immutability of an object, or to provide references to private data. This is a security risk. To avoid it, checks the validity (invariants) of the deserialized object within the readObject method. Also is critical to defensively copy any field containing an object reference that a client must not posses.
  • Typesafe enum and singletons should use readResolve to ensure their characteristics when deserialized.


Click below links to know more

Comments

Popular posts from this blog

Advantages & Disadvantages of Synchronous / Asynchronous Communications?

  Asynchronous Communication Advantages: Requests need not be targeted to specific server. Service need not be available when request is made. No blocking, so resources could be freed.  Could use connectionless protocol Disadvantages: Response times are unpredictable. Error handling usually more complex.  Usually requires connection-oriented protocol.  Harder to design apps Synchronous Communication Advantages: Easy to program Outcome is known immediately  Error recovery easier (usually)  Better real-time response (usually) Disadvantages: Service must be up and ready. Requestor blocks, held resources are “tied up”.  Usually requires connection-oriented protocol

WebSphere MQ Interview Questions

What is MQ and what does it do? Ans. MQ stands for MESSAGE QUEUEING. WebSphere MQ allows application programs to use message queuing to participate in message-driven processing. Application programs can communicate across different platforms by using the appropriate message queuing software products. What is Message driven process? Ans . When messages arrive on a queue, they can automatically start an application using triggering. If necessary, the applications can be stopped when the message (or messages) have been processed. What are advantages of the MQ? Ans. 1. Integration. 2. Asynchrony 3. Assured Delivery 4. Scalability. How does it support the Integration? Ans. Because the MQ is independent of the Operating System you use i.e. it may be Windows, Solaris,AIX.It is independent of the protocol (i.e. TCP/IP, LU6.2, SNA, NetBIOS, UDP).It is not required that both the sender and receiver should be running on the same platform What is Asynchrony? Ans. With messag

XML Binding with JAXB 2.0 - Tutorial

Java Architecture for XML Binding (JAXB) is an API/framework that binds XML schema to Java representations. Java objects may then subsequently be used to marshal or unmarshal XML documents. Marshalling an XML document means creating an XML document from Java objects. Unmarshalling means creating creating a Java representation of an XML document (or, in effect, the reverse of marshaling). You retrieve the element and attribute values of the XML document from the Java representation. The JAXB 2.0 specification is implemented in JWSDP 2.0. JAXB 2.0 has some new features, which facilitate the marshalling and unmarshalling of an XML document. JAXB 2.0 also allows you to map a Java object to an XML document or an XML Schema. Some of the new features in JAXB 2.0 include: Smaller runtime libraries are required for JAXB 2.0, which require lesser runtime memory. Significantly, fewer Java classes are generated from a schema, compared to JAXB 1.0. For each top-level complexType, 2.0 generates a v