Java | Techartifact

May 29, 2012June 25, 2012

Use of serialVersionUID

SerialVersionUId play an vital role in the serialization. SerialVersionUId is used for version control of object.Consequence of not specifying serialversionUID is that when you add or modify and field in class then already serialized class will not able to recover because serialVersionUID generated for new class and old serialized object will be different.

Java serialization process relies on correct serialVersionUID for recovering state of serialized object and throw java.io.InvalidClassException in case of serialVersionUID mismatch.

The serialVersionUID is a universal version identifier for a Serializable class. Deserialization uses this number to ensure that a loaded class corresponds exactly to a serialized object. If no match is found, then an InvalidClassException is thrown.

Guidelines for serialVersionUID :

* always include it as a field, for example: “private static final long serialVersionUID = 7526472295622776147L; ” include this field even in the first version of the class, as a reminder of its importance
* do not change the value of this field in future versions, unless you are knowingly making changes to the class which will render it incompatible with old serialized objects
* new versions of Serializable classes may or may not be able to read old serialized objects; it depends upon the nature of the change; provide a pointer to Sun’s guidelines for what constitutes a compatible change, as a convenience to future maintainers

In Windows, generate serialVersionUID using the JDK’s graphical tool like so :

* use Control Panel | System | Environment to set the classpath to the correct directory
* run serialver -show from the command line
* point the tool to the class file including the package, for example, finance.stock.Account – without the .class
* (here are the serialver docs for both Win and Unix)

readObject and writeObject :

* readObject implementations always start by calling default methods
* deserialization must be treated as any constructor : validate the object state at the end of deserializing – this implies that readObject should almost always be implemented in Serializable classes, such that this validation is performed.
* deserialization must be treated as any constructor : if constructors make defensive copies for mutable object fields, so must readObject
* when serializing a Collection, store the number of objects in the Collection as well, and use this number to read them back in upon deserialization; avoid tricks using null

Other points :

* use javadoc’s @serial tag to denote Serializable fields
* the .ser extension is conventionally used for files representing serialized objects
* no static or transient fields undergo default serialization
* extendable classes should not be Serializable, unless necessary
* inner classes should rarely, if ever, implement Serializable
* container classes should usually follow the style of Hashtable, which implements Serializable by storing keys and values, as opposed to a large hash table data structure

/**
* Determines if a de-serialized file is compatible with this class.
*
* Maintainers must change this value if and only if the new version
* of this class is not compatible with old versions. See Sun docs
* for * /serialization/spec/version.doc.html> details.
*
* Not necessary to include in first version of the class, but
* included here as a reminder of its importance.
*/
private static final long serialVersionUID = 7526471155622776147L;

[Post New]posted Monday, May 09, 2005 10:44 PM private message
Quote [Up]
*g* as you mention “Java RMI”… it says:

“The downside of using serialVersionUID is that, if a significant change is made (for example, if a field is added to the class definition), the suid will not reflect this difference. This means that the deserialization code might not detect an incompatible version of a class.”

and furtheron suggests to implement readObject & friends and writing a version “manually”.

All this in order to gain performance:

“Setting serialVersionUID is a simple, and often surprisingly noticeable, performance improvement. If you don’t set serialVersionUID, the serialization mechanism has to compute it. This involves going through all the fields and methods and computing a hash. If you set serialVersionUID, on the other hand, the serialization mechanism simply looks up a single value.”

Ref – http://sprasanth.blogspot.com/2009/07/what-is-use-of-setting-serialversionuid.html

January 24, 2012January 23, 2012

JSP EL expression is not evaluated

JSP or EL expression is not evaluated. I have seen couple of times JSP directly displaying the el-expression on webpages.

It may be because of couple reasons

1) Typo in your jsp.
2) Attributes are not set in reqeust or pageContext.
3) You have not enabled EL expression in your JSP or not enabled in your web container.

From Servlet specs 2.5 finally El expression are enabled by default. You don’t need enabled them manually in your JSP.

In case you are using older version Servlet Container, add following line to enable them.

<%@ page isELIgnored="false" %>

January 23, 2012June 25, 2012

SpringMVC example with Maven

Spring MVC is part of Springframework. It allow us to create application based on MVC design pattern in way that, we can leverage other features of Spring like authentication, ORM, AOP and others.

In Spring MVC core component is the DispatcherServlet{link}, It works as front-controller. All request are processed by DispatcherServlet. It is also responbile for deleting request to suitable handlers.

Structure

We are using standard Maven web project structure

Dependencies

        <!-- for compile only, your container will provide this  -->
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
            <scope>provided</scope>
        </dependency>
        <!-- Spring-->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>3.0.0.RELEASE</version>
        </dependency>
        <!-- JSTL -->
        <dependency>
            <groupId>taglibs</groupId>
            <artifactId>standard</artifactId>
            <version>1.1.2</version>
        </dependency>

Request Controller

You can use or extend any of controller that comes from Spring or create you own by extendng AbstractController and implement handleRequestInternal method.

package com.techartifact.example.springmvc.controller;


import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.mvc.AbstractController;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class HelloController extends AbstractController {

    private String message;

    public void setMessage(String message) {
        this.message = message;
    }

    @Override
    protected ModelAndView handleRequestInternal(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) throws Exception {
        ModelAndView modelAndView = new ModelAndView("hello");
        modelAndView.addObject("message", message);
        return modelAndView;
    }
}

Flow in a Spring MVC application is as follows:

The request is received by our DispatcherServlet

DispatcherServlet has responsibility to find the controller for request. This process would be done in HandlerMapping phase.
After controller has been found, DispatcherServlet will forward the request to Controller.
Controller has the business logic to compute what model it will return to Dispatcher. It means Controller will return Model and view where it needs to displayed
Once the ModelAndView has been dispatched to the DispatcherServlet from controller, DispatcherServlet will asociate the view name sent by the Controller with the specified view.
After the view had been resolved, our DispatcherServlet will pass our Model object to the concrete View.

View

In this example we are using jsp for view

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
    <title>SpringMVC Hello world</title>
</head>
<body>
Message from Spring "${message}"
</html>

Spring Configuration

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean name="/hello.htm" class="com.techartifact.example.springmvc.controller.HelloController">
        <property name="message" value="This is sample message"/>
    </bean>

    <bean id="viewResolver"
          class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="prefix">
            <value>/WEB-INF/jsp/</value>
        </property>
        <property name="suffix">
            <value>.jsp</value>
        </property>
    </bean>
</beans>

Web descriptor

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
         version="2.5">

    <display-name>Spring MVC example</display-name>

    <servlet>
        <servlet-name>springapp</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>WEB-INF/spring-mvc.xml</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>springapp</servlet-name>
        <url-pattern>*.htm</url-pattern>
    </servlet-mapping>

    <welcome-file-list>
        <welcome-file>index.jsp</welcome-file>
    </welcome-file-list>

</web-app>