Class Data Sharing

Class data sharing (CDS) a feature introduced in J2SE 5.0 reduces the startup time for Java
programming language applications.

When the JRE is installed on 32-bit platforms using the Sun provided installer, the installer loads a set of
classes from the system jar file into a private internal representation, and dumps that representation to a file,
called a "shared archive".Class data sharing is not supported in Microsoft Windows 95/98/ME.

During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those
classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes.

The primary motivation for including CDS in the 5.0 release is the decrease in startup time it provides.
CDS produces better results for smaller applications because it eliminates a fixed cost: that of loading
certain core classes. The smaller the application relative to the number of core classes it uses, the
larger the saved fraction of startup time.


The footprint cost of new JVM instances has been reduced in two ways. First, a portion of the shared archive,
currently between five and six megabytes, is mapped read-only and therefore shared among multiple JVM processes.
Previously this data was replicated in each JVM instance. Second, since the shared archive contains class data
in the form in which the Java Hotspot VM uses it, the memory which would otherwise be required to access the
original class information in rt.jar is not needed. These savings allow more applications to be run concurrently
on the same machine.

Regenerating Shared Archive

To regenerate the share archive use the following command:

java -Xshare:dump

Diagnostic information will be printed as the archive is generated.

Manually Controlling Class Data Sharing

The class data sharing feature is automatically enabled when conditions allow it to be used. The following command
line options are present primarily for diagnostic and debugging purposes and may change or be removed in future
releases.

-Xshare:off
Disable class data sharing.

-Xshare:on
Require class data sharing to be enabled. If it could not be enabled for various reasons, print an error message and exit.

-Xshare:auto
The default; enable class data sharing whenever possible.

XML Naming Conventions (Best Practices)

XML is the base of Web 2.0 development. While writing a web service to integrate products, I learned some best practices with XML naming conventions.

An XML element is everything from (including) the element's start tag to (including) the element's end tag.

An element can contain other elements, simple text or a mixture of both. Elements can also have attributes.

<bookstore>
<book category="CHILDREN">
<author>J K. Rowling</author>
<year>2005</year>
<price>29.99</price>
</book>
<book category="WEB">
<author>Erik T. Ray</author>>
<year>2003</year>
<price>39.95</price>
</book>
</bookstore>>

In the example above, and have element contents, because they contain other elements. has text content because it contains text.

In the example above only has an attribute (category="CHILDREN").

XML Naming Rules

XML elements must follow these naming rules:

1. Names can contain letters, numbers, and other characters
2. Names cannot start with a number or punctuation character
3. Names cannot start with the letters xml (or XML, or Xml, etc)
4. Names cannot contain spaces

Any name can be used, no words are reserved.

Best Naming Practices

1. Make names descriptive. Names with an underscore separator are nice: , .
2. Names should be short and simple, like this: not like this: .
3. Avoid "-" characters. If you name something "first-name," some software may think you want to subtract name from first.
4. Avoid "." characters. If you name something "first.name," some software may think that "name" is a property of the object "first."
5. Avoid ":" characters. Colons are reserved to be used for something called namespaces (more later).
6. XML documents often have a corresponding database. A good practice is to use the naming rules of your database for the elements in the XML documents.
7. Non-English letters like éòá are perfectly legal in XML, but watch out for problems if your software vendor doesn't support them.

Reference : http://www.w3schools.com/xml/xml_elements.asp

Apache AXIS2 Web Service Client

This article covers details about writing a web service client using Apache AXIS2 API. The article explains the various API using code snippets and covers parameters require by various methods of web service client API.

Apache AXIS2 web service API mainly consists of two type of objects ServiceClient and OperationClient. ServiceClient provides basic APIs to send and receive SOAP messages, for advanced methods you require Operation Client.

To provide target URL you need to define a EndPointReference type of object.

EndpointReference targetEPR = new EndpointReference(http://localhost:8080/axis2/services/helloworld);

Various options can be given to web service client by creating an Options object. The reference point defined is set into the options along with the Transport protocol.

Options options = new

Options();

options.setTo(targetEPR);

options.setTransportInProtocol(Constants.TRANSPORT_HTTP);

Now create a service client and pass these options to service client using setOptions API of service client.

ServiceClient sender = new ServiceClient();

sender.setOptions(options);

So, till now we have created a service client and provided the various options to it, next step is creating the payload of SOAP message that will be send in the web service call. AXIS2 provides AXIOM (AXIS Object model) to create XML Structure. Following code snippet creates the payload message.

OMFactory fac = OMAbstractFactory.getOMFactory();

OMNamespace omNs = fac.createOMNamespace("http://ws.apache.org/axis2", "");

OMElement method = fac.createOMElement("sayHello", omNs); //Method to be invoked.

OMElement value = fac.createOMElement("parameter1", omNs);

value.addChild(fac.createOMText(value, "Sachin" ));

method.addChild(value);

value = fac.createOMElement("parameter2", omNs);

value.addChild(fac.createOMText(value, "Thapa" ));

method.addChild(value);

Finally use the sendReceive API of ServiceClient to send SOAP request and receive response.

OMElement result = sender.sendReceive(method);

System.out.println(result);

The result object contains the response received from the server.

Project Properties Holder - Singleton Design Pattern Example

A very common requirement in most of the project is managing project specific properties. Certain properties that are required at various points of flow in a project. Mostly people would like to have a solution in which to change these properties they dont have to dig out the code and change the values. Instead they would like to have some file external to the code, so that anybody with or without knowledge of code can change it. A few examples for such properties can be:

a) A project connects to a 3rd party, one may like to store the URL for the connection in a properties file.

b) A project generates a output file, one may like to store the prefix or naming convention pattern in the properties file.

There can be many more examples. Now we need to look out for a solution so that we have single point to fetch these properties. The answer comes from Singleton design pattern.

Create a singleton class PropertiesHolder.java as shown below:

import java.io.IOException;
import java.util.Properties;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public class PropertiesHolder
{
private final Log log = LogFactory.getLog(PropertiesHolder.class);
private Properties properties = null;
private static PropertiesHolder holder = null;


public static PropertiesHolder getInstance()
{
if(holder == null)
{
holder = new PropertiesHolder();
holder.init();
}
return holder;
}
private PropertiesHolder()
{

}
private synchronized void init()
{
if(properties == null)
{
try
{
properties = new Properties();
properties.load(PropertiesHolder.class.getResourceAsStream("/project.properties"));
}
catch (IOException e)
{
log.error("Error loading runtime properties file.", e);
}
}
}

public String getProperty(String propertyName)
{
return properties.getProperty(propertyName).trim();
}
}

Project properties will be loaded once when first call is made to get a property. Any properties that are required to be changed are to be changed in project.properties file.

You may like to have a method to set property as well, the set property method will be required to update the Properties object and write that to file as well. In case the number of properties are too many and required to managed by an Admin, you can provide a UI over it as well.