Pragmatic Java

JAXB and Java 5 Enums

2011-09-23T09:51:00.000-07:00

In my previous post about Java 5 Enums, I wrote about how Java 5 provides capabilities to add behavior (via member fields and methods) within the enum class. This can be leveraged to provide the switching-like on the enumeration constants. So instead of the following code fragment:
We can define an abstract method in the Enum specification, and override that method in each of the Enum definitions as shown here. However there can be cases where it is not possible to change the Enum class in order to define an abstract method, if the Enum class has been generated, such as via JAXB compiler. In that case, the only way we can provide any custom behavior is by programming a switch construct as above in a class that leverages the enum.
Digressing a little bit from the main point, I would also like to point out how JAXB treats different XSD enum definitions. See the examples below from a file, example.xsd which contains the 2 schema definitions, viz. CountryCurrencyEnum and CountryEnum.

The above example demonstrates 2 Enum examples. The currency Enum is an example of inline definition of the Enum, while the Country enum is an example of a external Enum definition. When you run the latter explicit enum definition through the XJC compiler, it produces a separate Enum class as below:

package com.examples;

import javax.xml.bind.annotation.XmlEnum;
import javax.xml.bind.annotation.XmlEnumValue;
import javax.xml.bind.annotation.XmlType;

@XmlType(name = "CountryEnum")
@XmlEnum
public enum CountryEnum {

    @XmlEnumValue("UnitedStates")
    UNITED_STATES("UnitedStates"),
    @XmlEnumValue("France")
    FRANCE("France"),
    @XmlEnumValue("UnitedKingdom")
    UNITED_KINGDOM("UnitedKingdom"),
    @XmlEnumValue("Japan")
    JAPAN("Japan");
    private final String value;

    CountryEnum(String v) {
        value = v;
    }

    public String value() {
        return value;
    }

    public static CountryEnum fromValue(String v) {
        for (CountryEnum c: CountryEnum.values()) {
            if (c.value.equals(v)) {
                return c;
            }
        }
        throw new IllegalArgumentException(v);
    }
}

However the XJC compiler will produce the following file when it sees the inline Enum definition.

package com.examples;

import java.io.Serializable;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlType;

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "CountryCurrencyEnum", propOrder = {
    "currency",
    "country"
})
public class CountryCurrencyEnum
    implements Serializable
{

    private final static long serialVersionUID = 2010L;
    @XmlElement(required = true)
    protected String currency;
    @XmlElement(required = true)
    protected CountryEnum country;

    public String getCurrency() {
        return currency;
    }

    public void setCurrency(String value) {
        this.currency = value;
    }

    public CountryEnum getCountry() {
        return country;
    }

    public void setCountry(CountryEnum value) {
        this.country = value;
    }
}

So if we are interested in generating Java 5 style enums via JAXB, we are better off creating a separate definition in the xsd file.

Customizing Maven's lifecycle

2011-08-20T14:55:00.000-07:00

Every project has a lifecycle from project initiation all the way through regular production releases. A typical lifecycle involves at least the basic steps of getting all the resources together, compilation of source-code, unit-tests, integration-tests, packaging to create the custom-format. Maven formalizes this concept into a “default” lifecycle that every project is expected to have.

According to Maven, a lifecycle is made up of a sequence of phases. Each phase has zero or more plugin goals bound to it. Some of the core plugin goals are bound to the core phase steps by default, e.g the compiler plugin’s compile goal is bound to the compile phase. A more clear second example would be the Surefire plugin’s test goal is bound to the unit test phase. However, some phases are free-form and not necessary part of the core of the default lifecycle, they will be activated only when a corresponding plugin goal bound to that phase by default is configured. At the same time, some plugins and their goals are free-form and it is upto the developer to bind them to a particular phase.

Maven site lists all the following goals as part of the default lifecycle for any project regardless of the packaging type. Here are a few examples on what aspects of the project build we can customize by leveraging what plugins.

1.validate - Validates the project is correct and all necessary information is available. The enforcer plugin can be used here to enforce a few environment-specific constraints on the project.
Eg.

            
                org.apache.maven.plugins
                maven-enforcer-plugin
                
                    
                        enforce-versions
                        
                            enforce
                        
                        
                            
                                
                                    2.0.10
                                
                                
                                    1.6

2. initialize - Initialize build state, e.g. set properties or create directories. An example would be to use some programmatic plugins like antrun or groovy to generate custom properties. In the example below, the property ‘buildtime’ was created during build-time and it will be used inside the manifest file to mark the time the jar/war/ear was created.

            
                org.codehaus.mojo
                groovy-maven-plugin
                1.3
                
                    
                        generate-resources
                        
                            execute
                        
                        
                            
                                import java.util.Date
                                import java.text.MessageFormat
                                def buildtime = MessageFormat.format("{yyyy-MM-dd HH:mm:sss}", new Date())
                                project.properties['buildtime'] = buildtime

3.generate-sources - Generate any source code for inclusion in compilation. Projects that use webservices or any of the Java-XML bindings, like JAXB2, XMLBeans, Castor can make use of the corresponding plugins (e.g. axistools:wsdl2java, jaxb2:xjc, xmlbeans:xmlbeans, castor:castor) to generate any source code in this phase. These plugin goals bind by default to this lifecycle phase so that you do not have to explicitly mention it.


            
                org.codehaus.mojo
                jaxb2-maven-plugin
                1.3.1
                
                    
                        xjc
                        
                            xjc
                        
                    
               
               
                    com.example.myschema

4. process-sources - Process the source code, for example to filter any values from within the source code. More on filtering in a later blog.
5. generate-resources - Generate resources for inclusion in the package like WSDLs in a web-services project (e.g axistools:java2wsdl), or Hibernate Configuration XML or hbm.xmls (hibernate3:hbm2cfgxml)
6. process-resources - Copy and process the resources into the destination directory, ready for packaging. This is also a great place to filter any values from within the resources file. More on filtering in a later blog.
7. compile - This is the most obvious phase. Although the compiler plugin is part of the core lifecycle and need not be defined explicitly to be attached to any phase, there is often a need to customize the JDK version to use. Eg

            
                org.apache.maven.plugins
                maven-compiler-plugin
                
                    1.6
                    1.6
                    true

8. process-classes- This phase is used to post-process the generated class files from compilation, for example to do bytecode enhancement on Java classes.
9. generate-test-sources - This is conceptually same as generate-sources phase as above, except that we are generating test source code here.
10. process-test-sources - This phase is used to process test source files, e.g to filter any values, make program variables point to a test DB location instead of production DB location etc.

            
                org.apache.maven.plugins
                maven-antrun-plugin
                
                    
                        update-test-sources
                        process-test-sources
                        
                            run
                        
                        
                            
                                
                                    [test-DB-path-placeholder]
                                    ${testDB.path} // testDB.path is a locally defined property.

11. generate-test-resources - This phase is used to create resources for testing. E.g. Let's say your project's tests are off some companydata.dat file which is a part of the companycore.jar. Since your project is interested only in this data file for the purposes of testing, you could use maven-dependency-plugin to unpack the companycore.jar, extracting only that file into your test-resources directory.

            
                org.apache.maven.plugins
                maven-dependency-plugin
                
                    
                        unpack-test-resources
                        generate-test-resources
                        
                            unpack
                        
                        
                            
                                
                                    com.company.core
                                    core-artifacts
                                    1.0
                                    test-jar
                                    true
                                    companydata.dat
                                
                            
                            ${build.testResourcesDir}

12. process-test-resources - This phase is used to copy and process the resources into the test destination directory.
13. test-compile - The compiler plugin compiles the test source code into the test destination directory.
14. process-test-classes - Conceptually same as process-classes to do any byte code enhancement.
15. test - The Surefire plugin runs tests using a suitable unit testing framework. You may need to configure the plugin to skipTests or exclude any particular test class that are causing the build to fail. This may be useful during active development phase.

            
                org.apache.maven.plugins
                maven-surefire-plugin
                
                    
                        **/TestFeatureX.java

16. package - Take the compiled code and package it in its distributable format, such as a JAR. You can request Maven to package source files and test source files into respective jars via maven-jar-plugin and maven-source-plugin in addition to the distributable class file jar that it creates.

            
                org.apache.maven.plugins
                maven-jar-plugin
                
                    
                        
                            test-jar
                        
                    
                
            
            
                org.apache.maven.plugins
                maven-source-plugin
                
                    
                        attach-sources
                        package
                        
                            jar
                        
                    
                
            
            
                org.apache.maven.plugins
                maven-war-plugin
                
                    
                        false
                        
                            true
                        
                        
                            ${timestamp}

17. verify- This phase can be used to run any checks to verify the package is valid and meets quality criteria. It is a great place to enforce any source code formatting styles.

            
                org.apache.maven.plugins
                maven-checkstyle-plugin
                
                    
                        verify
                        
                            checkstyle
                        
                    
                
                
                    path_to/checkstyle_rules.xml
                    true
                    true

So the above list gives a fair idea on how you can leverage Maven plugins to customize your build lifecycle. The above are just brief samples. Any ideas beyond the above usage of plugins in various build phases is more than welcome.

Maven's assumptions

2011-07-30T22:16:00.000-07:00

Maven does both - 'makes assumptions' as well as 'enforces' a lot of standards and good practices for project programming and management at an enterprise-level. It also provides some good features such as resource filtering, though not enabled by default, suggest good programming practice. I wish to list down all of them as they come to my mind from the very obvious to the subtle ones below:

Projects would have a standard directory layout relative to project's home directory to place source code, target binaries, test source code, test binaries, resources etc as described in the Introduction to Standard Directory Layout.
Projects would adopt unit-testing as a standard practice by including the test-compile and test phases as part of the build lifecycle. Maven even goes a step further by failing a build if the test source does not compile or the unit tests fail in its default build lifecycle.
Projects provide a clean directory/folder separation between application source code and the resources required (such as Spring applicationContext files, Hibernate configuration files, log4j properties file etc) and not put everything together in project home folder.
Projects need not hardcode application properties inside the configuration resources or source code and instead make use of resource filtering - i.e. a property like jdbc.driverName could be externalized in the /src/main/filters and its value will be substituted wherever it is referenced. Thus any changes to it are localized to one file under /src/main/filters although it can be referenced in several places in configuration and code.
Modern-day applications (represented by an aggregate project model / POM in Maven) will be divided into separate modules - app-domain-model, app-DAO, app-business-logic, app-web-modules, app-webservices-modules, app-utils etc - instead of old-school monolithic applications. Maven multi-module projects and the Reactor plugin help achieve this.
Projects would need to be built for various platforms (Windows, Unix, Linux etc) and deployment environments (dev, staging, test, production) and builds do differ based on the platform and enviroment needed. Eg. different database servers required for each enviroment thereby a different jdbc.url, jdbc.username, jdbc.password for each environment. Maven Profiles are a great feature that if leveraged well can make the build process seamless across environments.

Maven references

2011-07-30T21:03:00.000-07:00

Recently I have been learning Maven as it is widely deployed and used at an organizational level in a very clever and effective manner. However, the Maven documentation, although quite extensive for an open-source project does not flow logically to educate a newbie. After scouring through most of the available online information in a not so logical progression and then trying to connect the pieces together, I came to a conclusion that the following would be the ideal order to comprehend Maven.

Online reference books made available by Sonatype.

All about Maven settings.

The settings.xml file in your Maven installation directory/conf
How to configure Maven settings
Maven settings reference
Settings model reference

Core of Maven - Project Object Model and all its intricacies - multi-module builds, profiles, reactors etc

CVS and (no) Atomic Commits

2011-07-12T13:57:00.000-07:00

Every project that I have worked so far has used a different version control system. My history of using version control systems has been thus - Rational ClearCase in my very first job/project, then Visual Sourcesafe, then Subversion for a very brief period of time (about 3 months) and then Perforce for the longest time as yet(for a little over 4 years) and now I am currently using CVS.

Using Perforce was a pleasant experience and its atomic commits combined with its changelist/changeset feature is something that I am missing while using CVS currently. In CVS, each file committed to the repository has its own, independent version number and history which sure is a limitation. I do not remember enough about Rational ClearCase except that its config-specs pretty much allowed a much efficient branching and merging in a manner that could emulate atomic commits. So this blog entry is about atomic commits and changesets and how they reduce the frequency of build breaks which seem to happen every once in a while in a high-traffic team workload.

A typical reason why a build could break is that developers fail to commit all of the files that go in as part of the task or a bug fix. As a consequence when one or more of the checked-in files try to access constructs(classes, methods, constants etc) newly introduced in the file that was forgotten to be checked-in. And thats the build breaking right in your face!

In my opinion, the kind of SCM being used as the source code repository(read CVS, Visual SourceSafe) can also be a contributing factor towards this. Ideally, when a developer commits files to the repository, it is great if the files are grouped together as a single atomic change towards the bug fix, new feature development or new task. So even mentally developers start to group all files together, thereby reducing the probability of a build break. Also in the event of a networking failure, atomic commits save the build by ensuring all or none of the files are submitted to the repository.

Perforce takes one more step beyond these atomic commits - if a developer modifies any of the local files that are mapped to the repository, it automatically puts them in a pool called 'changelist'. That way there is no chance that a developer could have forgotten to check-in any file.
Changelists serve two purposes:
- to organize your work into logical units by grouping related changes to files together
- to guarantee the integrity of your work by ensuring that related changes to files are checked in together.

Now different version control systems record this atomic commit differently in their history. For Subversion, a changeset/changelist is just a collection of changes with a unique name. The commit will create a new revision number which can forever be used as a "name" for the change. As per Subversion documentation:
"In Subversion, a global revision number N names a tree in the repository: it's the way the repository looked after the Nth commit. It's also the name of an implicit changeset: if you compare tree N with tree N-1, you can derive the exact patch that was committed. For this reason, it's easy to think of “revision N” as not just a tree, but a changeset as well. If you use an issue tracker to manage bugs, you can use the revision numbers to refer to particular patches that fix bugs—for example, “this issue was fixed by revision 9238”. Somebody can then run svn log -r9238 to read about the exact changeset which fixed the bug, and run svn diff -r9237:9238 to see the patch itself."

Perforce keeps track of each file's independent revision history as well as changelist numbers. Again you can associate changelist numbers with a bug/task tracking database and we can go back and forth between the SCM and the bug/task tracking database.

As I searched through the web, I did find some solutions and forums that discussed ways to get around this limitation which will be the next task on my agenda.

StackOverflow: List all the files checked in in a single cvs commit.
StackOverflow: Does-anyone-know-the-cvs-command-line-options-to-get-the-details-of-the-last-check-in?
CVSTrac
CVSps
ANT CVS Changelog task
CVS Hooks

Java 5 Enums

2011-06-29T20:22:00.000-07:00

Enums or enumerated types basically means a type that can be defined to have a certain set of fixed values as per the problem domain. Historically, enums (via enum keyword and any associated semantics) were missing from the featureset provided by versions upto Java 1.4.
However developers tried to achieve the "same enum effect" via something like this:
Example 1:

public class Currency {
  public static final int USD = 1;
  public static final int EUR = 2;
  public static final int GBP = 3;
  public static final int YEN = 4;
}

public class CurrencyConverter {
  public void convertCurrency(int fromCurrency, int toCurrency) { ... }

  public static void main(String[] args) {
    CurrencyConverter cc = new CurrencyConverter();
    cc.convertCurrency(Currency.USD, Currency.YEN);
  }
}

Additional currencies could be added to the Currency class by defining new constants. However, the convertCurrency (int, int) method lacks typesafety since the method signature indicates it can accept any int. However, the only acceptabe range of ints is 1 through 4. If we call the method outside of the range of agreed upon constants , e.g. convertCurrency(8, 10), the program fails.

The above can be avoided if we accept that Enumerations should be treated as a separate type. Implementing them as a sequence of integers is not helpful. To define enumerations as their own type, you do the following:

1. Replace the primitive ints above with 'static final' object references to the same class defining the enumerated constants.
2. Disallow any object creation of the class via a private constructor.

Example 2:

public final class Currency {
  public static final Currency USD = new Currency(1);
  public static final Currency EUR = new Currency(2);
  public static final Currency GBP = new Currency(3);
  public static final Currency YEN = new Currency(4);

  int value;

  private Currency(int value){
    this.value = value;
  }
}

public class CurrencyConverter {
   public void convertCurrency(Currency fromCurrency, Currency toCurrency) { ... }

   public static void main(String[] args) {
     CurrencyConverter cc = new CurrencyConverter();
     cc.convertCurrency(Currency.USD, Currency.YEN);
   }
}

The convertCurrency(Currency, Currency) now takes the Currency type instead of an int.

Secondly the acceptable values of Currency can only be defined inside the class due to the private constructor.This along with the fact that Currency is a final class ensures that Currency.USD, Currency.EUR, Currency.GBP and Currency.YEN are the only instances of the Currency class.

It also means that we can use the identity comparison (==) operator instead of the equals() method when comparing enum values. Identity comparison (==) is always faster than equals since we are only comparing object references in the former as opposed to object values in the latter.

However the above typesafety approach comes with the following disadvantages:
1. The above implementation is not Serializable and Comparable by default. It means we can have issues using them in the context of RMI and EJBs. In case, if we make them Serializable, constructing the object again creates a new instance of the same Currency by ignoring its private constructor completely and does not retrieve the same instance that was serialized. This means == comparison fails to identify the equality of a serialized and a non-serialized Currency. Also it means we no longer have a unique single instance of the currency type. We have to implement more boiler-plate code like implementing the readResolve method as suggested in http://www.javaworld.com/javaworld/javatips/jw-javatip122.html?page=2.

2. We cannot switch over the above enum values (remember it is easier to switch over ints) to get any business logic done. If we need to switch, it can be facilitated by providing a getValue() method that returns the int value.

Example 3:
Inside Currency class,

public class Currency {
      ....

      public int getValue() {
        return value;
      }
   }

   public class CurrencyConverter {
     public void convertCurrency(Currency fromCurrency, Currency toCurrency) { ... }
   }

Java 5 enums are a typesafe feature and overcome all the above problems listed with the Enumerated pattern. In addition to facilitating a way to list a set of constant values, they also provide features such as :

1. All defined enums implicitly extend from java.lang.Enum just as all objects implicitly extend from java.lang.Object.

2. The above feature taks care of default implementation for toString(), equals(), hashCode() methods.

3. They are Serializable and Comparable by default without generating duplicate instances during deserialization

4. They can be used in switch-case statements.

5. They can have behavior ( via member variables , methods , constructors, interface implementations etc) in addition to just specifying the constants.

Simplest example of Java 5 enum class with no additional behavior.

Example 4:

public enum Currency { USD,GBP,EUR,YEN }

public class CurrencyConverter
{
   public void printCurrencies() {
     for (Currency currency : Currency.values()) {
        System.out.println(currency);
        System.out.println(currency.ordinal());
   }
} 

}

Currency is an enum type, and all the above enum values, viz USD, GBP, EUR, YEN are of type Currency.

We can iterate through all the instances of Currency via the static values() method and take advantage of the toString() method in the print statement.

Example 5:
We can also add behavior via member fields and methods.

public enum Currency 
  {
    USD("United States"),
    GBP("United Kingdom"),
    EUR("Europe"),
    YEN("Japan")

    String country;

   public Currency(String country){
     this.country = country;
   }

   public Currency getCurrencyForCountry(String country) {
     return Currency.valueOf(country);
   }
 }

When you need to provide custom behavior based on the enum values, there are 2 ways of doing it. Either you switch case based on the enum values in the application code or a yet better way is to move the custom logic inside the enum class as follows:

Example 6:

public class Client 
   {
     enum HttpStatusCode
     {
        HTTP200("HTTP 200") {
         @Override
         void printMessage() {
            System.out.println("Successful Transaction ");
         }
     },
     HTTP401("HTTP 401 Error") {
        @Override
        void printMessage() {
          System.out.println("Authentication Failure");
        }
     },
     HTTP404("HTTP 404 Error") {
          @Override
          void printMessage() {
             System.out.println("Requested resource not found at specified location");
           }
     },
     HTTP500("HTTP 500 Error") {
       @Override
       void printMessage() {
          System.out.println("An error occured on server-side, please have   patience.");
      }
    };

    String statusString;

    HttpStatusCode(String statusString) {
       this.statusString = statusString;
    }

    abstract void printMessage();
 }

   public static void main(String[] args)
   {
     HttpStatusCode status = connectToServer();
     status.printMessage();
   }
 }

Switching over case statements could be used if you have no option of modifying the enum class code. This can happen in cases where the enum class is generated - e.g. using JAXB - from an XSD. More on this in a later blog.

So this covers the basics of Java 5 Enums. Java 5 also provides 2 data structures - java.util.EnumSet and java.util.EnumMap. More on this again will be in yet another blog.

Tomcat 6 and class loading

2009-01-05T08:32:00.000-08:00

In continuation with the previous blog entry, I would also like to write about Tomcat 6 (in particular) and class loading pattern that it adopts. Java allows the creation of custom class loaders by implementing the java.lang.ClassLoader. Now Tomcat 6 creates the following class loaders on startup. They share a parent-child relationship too, but NOTE that the delegation pattern is a bit different as will be explained

Although invisible in default installation of Tomcat 6, there are additional shared and server class loaders also available and they fall below the Common class loader in the hierarchy. Each of the class loaders has a responsibility to load classes from certain specific areas, noted below:

1. Bootstrap + Extension class loader - It loads the Java run-time classes in the JDK as well as any classes from the jars in the Extensions folder.

2. System class loader - As noted in the previous blog, the System class loader is responsible for loading the classes and the Jar classes present in the CLASSPATH. But an important NOTE here: Tomcat clears the user-set CLASSPATH entry in its startup.bat or startup.sh file. Instead it sets the CLASSPATH to be following: $CATALINA_HOME/bin/bootstrap.jar $CATALINA_HOME/bin/tomcat-juli.jar

3. Common class loader - This is a Tomcat 6 provided class loader. It loads the classes present in the following folder - $CATALINA_HOME/lib. These classes are available to Tomcat as well as all the web applications that will be hosted on this instance of Tomcat. Although developers can reference the APIs from the jars inside the $CATALINA_HOME/lib directory, they shouldn't be placing their own custom classes and/or jars in there. If developers need certain custom classes and/or jars to be shared by all web applications, then they should be placed where the shared class loader can see them. Note that Tomcat 6.0.14 the $CATALINA_HOME/shared/lib directory does not exist. So this can be done in Tomcat 6 as foll:

Create your own $CATALINA_HOME/shared/lib directory.
Modify $CATALINA_HOME/conf/catalina.properties by changing the line: shared.loader = ${catalina.home}/shared/lib

However the above does not apply to certain 3rd party libraries such as database drivers etc where Tomcat itself would need to set up data sources. Such jars have to be placed in the $CATALINA_HOME/lib folder for the common class loader to see. One can also add more jars for the common class loader without placing them under the $CATALINA_HOME/lib folder. This can be done by modifying $CATALINA_HOME/conf/catalina.properties by changing the property common.loader as above.

4. WebappX class loaders - Tomcat creates a class loader for every webapp that is deployed in its instance. This class loader loads classes under WEB-INF/classes and WEB-INF/lib folder. It is for these class loaders where the delegation model deviates, thanks to the Servlet Specification which states as follows: "It is recommended also that the [web] application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs."
However the above specification cannot override the Java standard delegation model of delegating to Bootstrap and System class loaders. It only is used to override the parent-child relationships that are introduced by Tomcat - ie. Common, Shared and WebappX class loaders. So when an application requests a class, the class loading hierarchy is as follows:

The bootstrap class loader looks in the core Java classes folders.
The system class loader looks in the $CATALINA_HOME/bin/bootstrap.jar and
$CATALINA_HOME/bin/tomcat-juli.jar
The WebAppX class loader looks in WEB-INF/classes and then WEB-INF/lib
The common class loader looks in $CATALINA_HOME/lib folder.
The shared class loader looks in $CATALINA_HOME/shared/classes and $CATALINA_HOME/shared/lib if the shared.loader property is set in conf/catalina.properties file.

Java and Class loading delegation model

2009-01-04T18:25:00.000-08:00

The role of a class loader in Java is to hide the details of loading classes - like searching the file system (local as well as network) for the class file, loading the class file, returning it to JVM as a Class class so that JVM can use the Class class to instantiate the requested object in the application. Since J2SE, the JVM is provided 3 distinct primary classloaders -

Bootstrap class loader - This class loader is written in native language and comes as part of the JVM implementation. It loads all the core Java classes. (e.g java.lang.* etc). The location of these jars depends on the implementation of JVM. Sun's JVM looks in the jdk/jre/lib directory.
Extension class loader - Usually, developers make use of the CLASSPATH environment variable to load application classes, 3rd party jars etc. However, the CLASSPATH can become too unwieldy to handle and prone to errors using this approach. So since Java 1.2 , we can drop the 3rd party jars into a standard extension directory - jdk/jre/lib/ext - and JVM will find them. The extension class loader loads all the classes found in one or more of these extension directories.
System class loader - This class loader locates and loads the classes in the directories and jar files specified on the CLASSPATH variable. It also loads the application's main class (the one containing the main() method).

The above 3 exist in a parent-child relationship as follows:

A delegation model is utilized by the JVM in order to determine which class loader amongst the above 3 to use to load a particular class. The model works in a "Delegate to Parent-Before-Looking" as follows: When an application requests a Class (e.g String str = "Hello World"; or MyClass myobj = new MyClass()) :

Each class loader delegates the request to its parent.
Once the topmost class loader is reached, the bootstrap class loader, it tries to load the class. If it is unable, its child will try.
If one of the class loaders finds the class, it is returned as a Class object. Following the delgation pattern , if the lowermost class loader in the hierarchy (System class loader) does not find the class, a ClassNotFoundException is thrown.

Java 5 Concurrency: The Executor framework

2008-12-07T19:42:00.000-08:00

The Java platform has always provided support for multi-threaded/concurrent programming. However, prior to Java 5, the support was in the form of primitive constructs in the programming language itself. Java 5 steps up and provides concurrency utility frameworks and data structures in the java.util.concurrent package. One of the utilities provided is the task scheduling framework better known as the Executor framework. The JVM runs as a process and our application is one of the threads in the JVM. There are various other "system" threads running to do tasks like garbage collection, memory management etc. But from the application's perspective, there is the single "main" thread to begin with. The application, in itself, can spawn a number of threads to perform various helper tasks for various reasons like performance etc. Prior to Java 5 , spawning a new thread to perform a task was most commonly done as follows, although you could also do by extending the Thread class, but it is not highly recommended:

public void mainMethod() {
 HelperTask task = new HelperTask(); // Step 1: Create an object representing the task
 Thread t = new HelperThread(task);  // Step 2: Create a new thread for executing the task
 t.start();                        //  Step 3: Start the new thread
}

public class HelperTask implements Runnable {
public void run() {
      doHelperTask();
}
}

We have the following issues:

Most of the code related to thread creation and task delegation to the thread is a part of the application itself. We need a way to abstract the above steps away from the application.
Also what if we have multiple helper tasks or a scenario where every single user action requires a new Thread to be spawned to process? Creating a lot many threads with no bounds to the maximum threshold can cause out application to run out of memory.
Secondly although threads are light-weight (but only as compared to the process) , creating them utilizes a lot of resources. In such a situation, having a ThreadPool is a better solution so that only fixed number of Threads are created and re-used later.
Another short-coming of the Runnable interface's void run() method is that the task executed within run() has no way of returning any result back to the main thread. So work-arounds designed around that would be that the asynchronous task either updates certain database table(s) or some file(s) or some such external data structure(s) to communicate the result to the main thread.

The Executor framework addresses all the above issues and in addition also provides additional life-cycle management features for the threads. The Executor framework consists of the following important interfaces:

Callable: This interface is similar in concept to Runnable interface, ie it represents the asynchronous task to be executed. The only difference is that its call() method returns a value, ie the asynchronous task will be able to return a value once it is done executing.
Executor, ExecutorService and ScheduledExecutorService - Each of these interfaces adds more functionality to the previous one in thread and their life-cycle management. The Executor abstracts the Thread creation (as seen in Step 1 above) and executes all Runnable tasks. The ExecutorService extends the Executor and is able to execute Callable tasks in addition to Runnable tasks. It also contains life cycle management methods. The ScheduledExecutorService allows us to schedule the asynchronous tasks thereby adding support for delayed and periodic task execution.
Future: This interface represents the result of the asynchronous task which itself could be represented as Callable. The ExecutorService which can execute Callable tasks returns a Future object to return the result of the Callable task.

Essentials of a Software Engineer

2008-11-13T09:04:00.001-08:00

Sites like Digg usually have highest number of "diggs" on stuff like "Top 5/10/n" things on varied topics. Recently a co-worker sent me one such popular article about "Top 10 concepts that every software engineer should know". This was just in time as I was preparing to start this blog about the various techniques that would enable a Java engineer to be more pragmatic regardless of the kind of applications being developed and the myriad of technologies/frameworks being used . In my opinion, it is more essential to know these principles thoroughly and put them in practice before jumping to learning any new frameworks. Most of the frameworks - open source or otherwise - are usually the usage of the design principles in practice to solve commonly encountered problems. Good Object-Oriented(OO) design is the key principle here. As Rod Johnson points out here, "It's possible to design a [J2EE] application so badly that, even if it contains beautifully written Java code at an individual object level, it will still be deemed a failure. A [J2EE] application with an excellent overall design but poor implementation code will be an equally miserable failure. ... adherence to good OO principles brings real benefits. OO design is more important than any particular implementation technology (such as [J2EE], or even Java). Good programming practices and sound OO design underpin good [Java/J2EE] applications. Bad Java code is bad J2EE code."

Overview of Web Service Stacks

2008-09-28T19:49:00.000-07:00

There are currently the following open-source Java Web Service stacks in the market today.There could be more that I am unaware of, but at least the following contribute more significantly to the market share.

Apache Axis1 and Apache Axis2
Apache CXF
Spring-WS
Sun’s Metro available via Java EE 5 GlassFish container
JbossWS
XFire - which is now merged and transformed to being CXF.

This article is a comparative interview with each of the web service stack’s Principal Engineers and their vision for their product. http://www.infoq.com/articles/os-ws-stacks-background The second article is a comparison between Apache’s 3 products – Axis1, Axis2 and CXF. http://www.theserverside.com/tt/articles/article.tss?l=AxisAxis2andCXF Both of these articles are non-biased articles with no claims of one being better than the other. They leave it up to users to pick the one most matching their needs and demands. Sun has now published the standards for Web Services and it has now become imperative for all the Web Service stacks to provide implementations of those for conformance. Every web service stack provides the core functionality of:

Providing an easy-to-use deployment option.
Correct Web service/operation invocation for the particular message(SOAP/REST). This further involves in the following order -

Receiving the message over the correct transport endpoint(Endpoint is an abstraction to represent URL and port),
Figure out the operation intended to perform based on the message, and then
Invoke the correct Java method mapping to the operation.

    3. Pre-processing the messages via handlers to perform various functions like authentication, logging, custom processing etc.
    4. Marshaling/Unmarshaling mechanism of the request and response structures to/from Java<=>XML.
   5. In addition, today's web service stacks are expected to provide implementations for the various WS-* standards that exist.

With respect to points # 2 and # 4 above, Mark Hansen has correctly pointed out:
The key technology for efficient SOA is efficient and accurate Java/XML mapping or more generically known as the OXM (Object-XML Mapping)as pointed out by Spring-WS. At the SOA level, system standards are specified using platform independent XML messages (SOAP/REST) and WSDL operations (which themselves are in XML). But at the language level (Java/C#/VB etc), the systems that are the real engines behind the functionality of SOA are implemented using objects and methods. The more seamless effortless and accurate OXM solution that a web service engine provides the more popular it will be.

Programming Java Web Services

2008-09-28T16:18:00.000-07:00

For someone who is a total newbie to the world of Java Web Services(JWS), here's a list of the different JSRs/standards within the realm of JWS that are available with Java EE 5 and Java SE 6. They all have a particular purpose in the whole orchestration of JWS.

JAX-WS 2.0 (Java API for Xml-Web Services) - specified by JSR 224.

JAXB 2.0 (Java API for Xml Binding) - specified by JSR 222.

WS-Metadata 2.0 (Web Services Metadata) - specified by JSR 181.

WSEE 1.2 - Web Services for Java EE - specified by JSR 109.

All these standards can be complex to understand at first, and after surfing a lot on the web for an in-depth perspective, I have finally landed on the book "SOA Using Java Web Services" by Mark D. Hansen.

Why do J2EE applications need Spring? The core of Spring explained...

2008-08-12T18:38:00.000-07:00

What is the core of spring? The real purpose of why it came to being and is so popular. Most Java/J2EE application code tend to become monolithic (read a single large code base) over time - i.e. the application code slowly diminishes to maintain its modularized form with the result that the dependency relation graph between the classes/objects gets really ugly with no standard form. Secondly the applications also need a lot of infrastructure services - like Life Cycle Management of their objects and important resources like database connections etc, Database Access, Transaction Management and many more.Even simple Java applications would at least require efficient management of their objects and its dependencies. Although standard J2EE API and the application servers implementing those API claim to provide all the infrastructure services, applications still tend to become monolithic and unwieldy. So we need simplicity and freedom in the following areas:

1. Externally configurable objects - It is always better to be able to configure objects externally, i.e. set their values externally without recompilation of Java code or involving developers. The whole beauty of the general concept of configuration is that any change made to it does not require a rebuild or redeployment.

2. Simple POJO based programming - If we are just able to concentrate on programming business logic and not spend time of writing infrastructural code, we speed up the time to deliver the project by at least 40%. Simplicity and speed usually are natural if we adopt the POJO-based programming model. But for a real application, we have to add code to the POJOs to access databases, coordinate transactions, locate services provided by the container/environment, and so on. We would like these tasks to be performed declaratively via configuration (and via annotations), without disturbing the POJO code.

3. Dependency Resolution - Java interfaces do provide a clear separation between a contract and implementation. Ideally we would want the client class to be dependent only on the interface class. But we still have to look up the implementation class that we want to use. If it is hard-coded in Java code, we lose the advantage of interfaces, because the client class now depends on the interface class and the implementation class. Eg. Let's say we have an interface I and 2 concrete implementations of it - say C1 and C2. The whole idea of having interface is to shield client from the concrete classes at compile-time. But the client class still had to know about C1 at compile-time. But the client class still ends up having something like this:

I iobj1 = new C1();
iobj1.executeMethod();

We do have to be aware of C1, otherwise we would never be able to work without real implementations. But it is better to have awareness outside of Java code.

4. Lookup of Resources - A Java object A, say, depending on another Java resource B or a resource like Database C, should not be concerned with looking up for them. We again need a way to externally configure lookup code. So how does Spring help us?

Spring helps us achieve the above by wiring the dependencies between objects, all external to Java code.

Spring is essentially a technology dedicated to enabling you to build applications using POJOs.The components/objects are simple POJOs providing simple getters and setters. The container wires all the objects passing the dependent objects to POJO properties or constructors.Spring achieves the above using the Dependency Injection mechanism.

Most importantly, Spring itself is modular and has a layered architecture. This means we can use just the core JavaBeans configuration management without using the MVC framework or AOP support or DAO support. This means we can create modularized applications of any kind; so you are not restricted to creating web-based enterprise Java applications.

A more detailed discussion on what Spring does and does not can be found here.

Program to an interface, not an implementation

2008-08-03T12:13:00.000-07:00

In the introduction of the GoF book, the GoF mention an important principle of reusable object-oriented design. The principle is: "Program to an interface, not an implementation". The basic reason behind it is to achieve the flexibility in choosing different implementations at run-time as many times via the interface. This is achieved because of the polymorphism feature of the OO languages. The power of interfaces is best understood in design patterns. Most of the design patterns such as Strategy, State, Command, Abstract Factory Method are actually the above principle in practice. Now how do we try to abide by the principle? The best way is to strive for having method signatures with more generic, interface or parent class type method parameters and return types. Also it is advisable to declare class member variables to be of a more generic, interface or parent class type rather than a concrete implementation. The advantages of using interfaces (pure interfaces and/or abstract base classes) are as follows:

It is always painless to depend on interfaces. Client classes depending on the interfaces remain unaware of the concrete classes they use indirectly via the interface , as long as the concrete classes adhere to the interface that clients expect. This makes the clients more resilient to changes in implementation details.
The above aspect makes unit testing also very easy. In order to test a client class that depends on a complex computation exposed by an interface, we can create a mock stub object that implements the interface to replace the complex computation object.
Depending on interfaces has benefits even beyond just programming. The more we depend on concrete classes, the more complex dependency structures become, as a result our build scripts and build processes also tend to be more unwieldy.

Erich Gamma, one of the GoF, explains in an interview: "This principle is really about dependency relationships which have to be carefully managed in a large app. It's easy to add a dependency on a class. It's almost too easy; just add an import statement and modern Java IDEs like Eclipse even write this statement for you.Interestingly the inverse isn't that easy and getting rid of an unwanted dependency can be real refactoring work or even worse, block you from reusing the code in another context. For this reason you have to develop with open eyes when it comes to introducing dependencies. This principle tells us that depending on an interface is often beneficial."