Java Class Loading mechanism is one of the darkest corners inside java virtual machine. The class loading concept describes the behavior of converting a named class into the bits responsible for implementing that class.

Wait a minute! “I never have to deal with it. Why do I need to know this bulky philosophy”, this might flash in your mind. In that case, think of below-

ClassNotFoundException

NoClassDefFoundError

ClassCastException

Sounds familiar?

Most of the developers have had this frustrating experience trying to debug some of these exceptions. Post Java2, class loading is no longer as simple as defining a CLASSPATH environment variable. J2EE application servers supplement the CLASSPATH with many different mechanisms. The Java ClassLoader is a crucial, but often overlooked, component of the Java run-time system.

Okay, so what really a ClassLoader is?

Let’s start with the basics. A Java program, isn’t a single executable file, but is composed of many individual class files containing the platform-independent byte code. During execution, classes are not loaded into JVM memory all at once, but based on demand, as needed by the program – this is where the ClassLoaders come into picture. A classloader is a subclass of the java.lang.ClassLoader class. Each classloader, in turn, is designed to work with one or more codesources. A codesource is a root location from which the JVM searches for classes. Codesources can be defined to represent physical storage of binary class files, URLs, or even classes generated on the fly.

What is Class Loading?

The term “class loading” refers to the process of locating the bytes for a given class name and converting them into a Java Class instance. All java.lang.Class instances within a JVM start life as an array of bytes, structured in the class file format defined by the JVM specification.

Class loading in J2SE environment

When a JVM is started (in all versions since JDK 1.2), it forms an initial classloader hierarchy composed of three loaders:

• The bootstrap (also known as “primordial”) loader is responsible for loading the core Java classes (rt.jar & i18n.jar). This “loader” is unique in that it is not actually a subclass of java.lang.ClassLoader but is implemented by the JVM itself.
• The extension loads classes from the jars in the JRE’s extension directory (jre/lib/ext). This provides a standard mechanism to introduce new functionality beyond the core Java classes. Calling getParent() on this instance will always return null, since the bootstrap loader is not an actual ClassLoader instance.
• The system loader is responsible for loading classes from the directories and jars listed on the command-line (-cp/-classpath) and/or the java.class.path and CLASSPATH system properties. If not otherwise specified, any user instantiated ClassLoader will have this loader as its parent.
• The user defined ClassLoader allows applications to customize class loading as per their needs

Phases of Class Loading

The entire class loading process can essentially be broken down into three phases-

• Loading
  • Locating the required class file and loading the bytecode
  • Gives a very basic memory structure to the class object. Methods, fields, and other referenced classes. A notable point here is that the referenced classes are not dealt with at this stage therefore, the class is not usable
• Linking
  • Bytecode verification – The class loader does a number of checks on the bytecodes
  • Class preparation – Prepares the necessary data structures that represent fields, methods, and implemented interfaces that are defined within classes
  • Resolving – Loads all the other referenced classes (Superclasses, Interface, Fields, Method signature, Local variables)
• Initialization – any static initializes contained within a class are executed

Three Principles of ClassLoader Operation

• Delegation Principal
  • According to this principle, if a particular class is not loaded already, the classloaders delegate the requests to load that class to their parent classloaders.
  • Since the System-Classpath classloader loaded the MyApp class, it first asks its parent, the extension classloader to load the class. The extension classloader asks the Bootstrap classloader to load java.util.Vector. Since java.util.Vector is a J2SE class, the bootstrap classloader loads it and returns.

• • In case MyApp creates new instance of MyClass, bootstrap & extension classloaders cannot find the class. Finally the request comes back to system classloader which finds the class and loads it.

• Visibility Principal
  • According to this principle, Classes loaded by parent classloaders are visible to child classloaders but not vice versa
  • For classes loaded by ClassLoader X, classes A, B and X are visible, but not class Y. Sibling classloaders cannot see each other’s classes.

• Uniqueness Principal
  • According to this principle, when a classloader loads a class, the child classloaders in the hierarchy will never reload the class. This follows from the delegation principle since a classloader always delegates class loading to its parents. The child classloader will load it (or try to load it) only if the parent hierarchy fails to load the class. Thus the uniqueness of the class is maintained. An interesting scenario emerges when both parent and child classloaders load the same

ClassLoader Namespaces

• Each classloader (or instance of a ClassLoader subclass) defines a unique and separate namespace.
• For a given class with name N, only one instance of class N may exist within a given classloader. But the same class can be loaded by two different classloaders
• JVM considers each class to be further qualified by the ClassLoader instance that loaded it. In effect, the full name of a class consists of its fully qualified class name plus its classloader
• If two different classloaders load com.test.cl.vo.B, there will be two Class instances, each with its own separate static data. Any attempt to cast an object from one to the other will result in a ClassCastException
• So, your singleton is per classloader hierarchy than the JVM

How to access a ClassLoader

• class.getClassLoader()
• classLoader.getSystemClassLoader()
• Thread.currentThread().getContextClassLoader()
• An application specific method to retrieve a classloader

In all the cases initial loader selection is critical because it defines the visibility.

Explicit v/s Implicit Class Loading

• Explicit class loading occurs when class is loaded using one of the following method
  • cl.loadClass() – where cl is an instance of java.lang.ClassLoader)
  • Class.forName() – the starting class loader is the defining class loader of the current class

If the Class whose name is specified is already loaded, classloader returns the reference to it from cache. Otherwise loader goes through the delegation model to load the class.

• Implicit class loading occurs when the class is loaded as a result of reference, inheritance or initialization. Again, class is either returned from cache or through the delegation model.

Classes are often loaded through a combination of explicit and implicit class loading. For example, a class loader could first load a class explicitly and then load all of its referenced classes implicitly.

Why to write a custom class loader?

Following are some of the catalysts-

• To allow class loading from alternative repositories – Load classes that are not in the classpath – over the network, out of a database, from Java source code, out of a plug-in directory, or generate them on the fly
• Selectively load a specific version – All application developers to check for update and selectively load classes from specific locations (jar/zip/folder).
• To allow the unloading of classes – This case is useful if the application creates large numbers of classes that are used for only a finite period. Because a class loader maintains a cache of the classes that it has loaded, these classes cannot be unloaded until the class loader itself has been de-referenced. For this reason, system and extension classes are never unloaded, but application classes can be unloaded when their classloader is.
• Security – Your ClassLoader could examine classes before they are handed off to the JVM to see if they have a proper digital signature.
• Encryption – It’s possible to create a ClassLoader that decrypts on the fly, so that your class files on disk are not readable by someone with a decompiler.
• Archiving – Want to distribute your code in a special format or with special compression? Your ClassLoader can pull raw class file bytes from any source it wants.

Common Class Loading Issues

• ClassNotFoundException
  • Thrown when an application tries to explicitly load a class using class name string and class (.class file) is not found in the classpath
  • Can be easily checked by enabling –verbose:class JVM argument

• NoClassDefFoundError
  • Thrown if the ClassLoader instance tries to implicitly load in the definition of a class and no definition of the class could be found.

• ClassCastException
  • Thrown as a result of incompatible types being found in a type comparison. It indicates that the code has attempted to cast an object to a subclass of which it is not an instance. (remember ClassLoader Namespace)
  • Two classes of the same fully qualified name are not equal to each other if they are loaded by different ClassLoaders. They cannot be cast to each other and such operations would result in a ClassCastException

Class Loading Options

Following Table summarizes the command-line options for setting the classpaths of the three standard class loaders:

Author – Yogendra sharma (YES)

browser search plugin

OpenSearch is a collection of simple formats for the sharing of search results.

OpenSearch description file

http://www.svnlabs.com/opensearch.xml

We have to create  a simple xml file for websites and search engines to publish search results in a standard and accessible format.

See below the code in action…….

Paste below block of code to HTML Heading section to add browser search plugin….

Source:
https://developer.mozilla.org/en/Creating_OpenSearch_plugins_for_Firefox

Accessing a Resource in Java

A resource is data(audio, vedio, image, text etc.) that  a program needs to access. Before accessing a resource by a Java program, the resorce is located on the underlying file system. Now, locating a resource on file system inside your project might be tricky for you.

There are following ways to locate a resource on file system from a Java Application-

a) Location dependent

b) Location Independent

Location Dependent

A resource can be located on file-system by specifying a relative url or an absolute url for resource.

For the eclipse project structure shown in picture, the data files can be accessed from ResourceReader.java as below-

File file1 = new File(“Data1.txt”);

File file2 = new File(“resource/Data2.txt”);

File file3 = new File(“data/com/Data3.txt”);

Apart from this, you have got the option to specify an absolute path of the resource.

File file1 = new File(“C://………../Data1.txt”);

While accessing the resources using the location dependent ways, you are not supposed to change the project folder structure later on because that will lead to change each and every piece of Java code which is involved in accessing these resources.

Well, the Java code change because of resource location change can be avoided by specifying  base location as environment variable. For exmaple – we can have an environment varibale as RESOURCE_BASE  whose value can be set as inside configurations and the variable can be used further inside your Java code to form the complete path for a resource.

String base = System.getProperty(“RESOURCE_BASE”, “”);

File file = new File(base + “/data/com/Data3.txt”);

Location Independent

The methods from Class and ClassLoader classes enable you to access resources independent of their location. Both classes provides similar methods to read system resources and non-system resources for exmaple: getResource and getSystemResource.

Tip :- A system resource is a resource that is either built-in to the system, or kept by the host implementation in, for example, a local file system.)

Using methods from java.lang.ClassLoader

For a System Resource, the ClassLoader methods search each directory, ZIP file, or JAR file entry in the CLASSPATH for the resource file, and, if found, returns either an InputStream, or the resource name. If not found, the methods return null. A resource may be found in a different entry in the CLASSPATH than the location where the class file was loaded.

For a Non-System Resource, the implementation of getResource on a class loader depends on the details of the ClassLoader class. Generally,all class loaders first tries to locate the resource as a system resource; if not found, the behavior is dependent on the ClassLoader class.

ClassLoader class exposes two sets of methods – one set returns URL of the accesses resource while other resturns InputStream.

Examples:

Data3.txt can be accessed from ResourceReader.java as–

URL url = ResourceReader.class.getClassLoader().getResource(”com/Data3.txt”);

Here the value of url will be the absolute path of file Data3.txt on file system. Note – the file Data3.txt is on classpath. Data2.txt is not available on classpath and hence cant be accessed using getResource mehod.

Data3.txt can be read as InputStream as below-

InputStream file = ResourceReader.class.getClassLoader().getResourceAsStream(”com/Data3.txt”);

Using methods from java.lang.Class

The method getResource() returns a URL for the resource. The URL (and its representation) is specific to the implementation and the JVM (that is, the URL obtained in one runtime instance may not work in another). Its protocol is usually specific to the ClassLoader loading the resource. If the resource does not exist or is not visible due to security considerations, the methods return null.

If the client code wants to read the contents of the resource as an InputStream, it can apply the openStream() method on the URL. This is common enough to justify adding getResourceAsStream() to Class and ClassLoader. getResourceAsStream() the same as calling getResource().openStream(), except that getResourceAsStream() catches IO exceptions returns a null InputStream.

Client code code can also request the contents of the resource as an object by applying the java.net.URL.getContent() method on the URL. This is useful when the resource contains the data for an image, for instance. In the case of an image, the result is an awt.image.ImageProducer object, not an Image object.

The getResource and getResourceAsStream methods find a resource with a given name. They return null if they do not find a resource with the specified name. The rules for searching for resources associated with a given class are implemented by the class’s ClassLoader. The Class methods delegate to ClassLoader methods, after applying a naming convention: if the resource name starts with “/”, it is used as is. Otherwise, the name of the package is prepended, after converting all periods (.) to slashes (/).

Important:- Observe the difference between behaviour of getResource() method from Class class and ClassLoader class. The method from Class class resolves the resource name as explained above and finally delegates it to ClassLoader.getResource().

Author – Yogendra sharma (YES)

Installation of Java

Login to server as root
# cd /opt

Download jdk 6 linux rpm bin package from sun (Java SE Development Kit (JDK))
http://java.sun.com/javase/downloads/index.jsp
http://java.sun.com/javase/downloads/widget/jdk6.jsp

# chmod 777 jdk-6u17-linux-i586-rpm.bin
# ./jdk-6u17-linux-i586-rpm.bin

Follow the onscreen instructions to complete jdk installation…. press space ….. press yes….. and Enter

Now we will find JDK folder at /usr/java/jdk1.6.0_17

Installation TomCat

Download tomcat source files and extract…

# wget http://www.trieuvan.com/apache/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.tar.gz
# tar xzf apache-tomcat-6.0.20.tar.gz
# ls

Move tomcat to /usr/java/tomcat/

# mv apache-tomcat-6.0.20 tomcat
# mv tomcat /usr/java/
# cd /usr/java/tomcat/

Set CLASSPATH for JAVA & TOMCAT

# vi /etc/profile    (set class path)

add source PATH to /etc/profile

export JAVA_HOME=/usr/java/jdk1.6.0_17
export CATALINA_HOME=/usr/java/tomcat
export PATH=$JAVA_HOME/bin:$PATH

# source /etc/profile

Start tomcat server….

# /usr/java/tomcat/bin/startup.sh

Start/Stop Tomcat

# cd /usr/java/tomcat/bin
# ./shutdown.sh
# ./startup.sh

Check tomcat status

# netstat -ntlp|grep 8080

Enjoy new server

We can use nusoap and pear library to invoke web service … there are some command line tools to consume services and generate/validate wsdl …..

1. wsdl (call method at CLI)
# wsdl WSDL_URL METHOD

2. soapUI
create wsdl project and use web services

3. wsdl2php
wsdl2php convert service methods as the class like structure
http://www.urdalen.no/wsdl2php/manual.php

4. SoapClient – PHP
$path_wsdl = “wsdl/svnlabs7.wsdl”;
$client = new SoapClient($path_wsdl, array(’trace’ => 1));
$request = array(’….. |wsdl request array| ……’);
$response = $client ->getLog($request);

5. nuSOAP
http://sourceforge.net/projects/nusoap/

Resources:
http://wsdlpull.sourceforge.net/
http://code.google.com/p/ezerphp/
http://www.mehtanirav.com/2008/12/26/xplanner-php-soap-client
http://code.google.com/p/wsdl2php-interpreter/
https://www.ohloh.net/p/php-wsdl-viewer
http://php.net/manual/en/book.soap.php
http://phpwebservices.blogspot.com/