Brief Introduction to Java Classloader

There are two kinds of class loaders: one is provided by system, another is user-defined.  The system provides three class loaders: bootstrap (load JVM core classes), extensions (load JVM extension classes) and system (load classes defined on the classpath).  Developers do not need know details of these class loaders, only need to consider user-defined class loaders.

Delegation

Java class loaders uses the proxy pattern.  When a class loader tries to find a class, it will delegate this job to its parent class loader first, and its parent class loader will also do the same thing.  Finally, use bootstrap class loader to load the Java core classes.  This proxy pattern is to guarantee the Java core classes safe. Because when JVM compares two classes, it not only use class full name, it also compares class loaders of these two classes are same or not.  So if not use the proxy pattern, Java core classes may be loaded by different class loaders.  That will result a same Java core class will be identified as different ones by JVM.

Defining loader and initiating loader

java.lang.ClassLoader has two methods related load class: defineClass and loadClass.  The difference is that loadClass method will start the class loading process, but defineClass method will do the load class job finally.  The class loader starts the class loading may be different with the class loader finished the class loading.  The former called initiating loader, and the latter called defining loader.  When JVM compares whether two classes are same with each other, JVM will use the defining loader, other than the initiating loader.

Thread-context class loader

From JDK 1.2, thread-context class loader has been imported.  It used to solve that how to load SPI implementation classes.  Because SPI interfaces are part of Java core library, so these classes will be loaded by bootstrap class loader, but bootstrap class loader cannot load implementations.  Because these implementations are involved at 3rd party libraries.  Class loader proxy model cannot solve this problem.  With thread-context class loader, this problem can be solved.  Because by default, a thread-context class loader is the system class loader, so classes on the classpath can be loaded.  And developers can make the thread-context class loader changed in their code to fit the web container or OSGi environments.

Web container

The web container like Tomcat and Jetty defined their own class loaders and also apply the proxy pattern.  But different with common class loader, the proxy pattern of the web container class loader is reversed.  Because different web apps will use different libraries.  But when load the core Java library, the web container class loader  use the same order.

Java Concurrency: Fair Lock

When use synchronized, the order of threads acquire a lock is not same as the order of threads request to acquire a lock.  If you want to have a fair lock mechanism, you should use Java 5 Lock.

java.util.concurrent.locks.ReentrantLock has a constructor with a boolean parameter. With this constructor, you can have fair lock mechanism.  ReentrantLock has a queue to contain threads which want to acquire this lock.  When a thread releases this lock, then the header will acquire this lock if the queue is not empty.

Use jOOQ to mock JDBC

When you want to do unit tests for the DB access layer of a project, you may need to mock JDBC API.  But it will be an awkward work if you do it with common Mock frameworks like JMock or Mockito.  At that moment, you can consider use jOOQ to do that.

jOOQ is a Java framework to help you to write type-safe SQL DML (there is a similar framework named QueryDSL.  But it is more powerful than jOOQ).  And it shipped with a JDBC mock class collection.  With these classes, you can mock JDBC API for your DB layer UT.

You can view the reference of jOOQ for details: JDBC mocking for unit testing.

SIP Servlet 2.0 POJOs

Recently I talked with SIP Servlet expert group member George Vagenas from TeleStax about how to route SIP message with annotation (The thread link).  He mentioned that there will be a great feature in SIP Servlet 2.0, which called SIP Servlet 2.0 POJOs.  This feature will provide some annotations.  With these annotations, you can write your SIP application with POJOs in SIP Servlet 2.0 container. One of my most favorite annotations is @SipPredicate.  With this annotation, you can route SIP message to your expected method.

The example of this annotation is following:

With this annotation, SIP Servlet container can know that whether a SIP message should be processed by the method with this annotation or not.

The link of the draft of SIP Servlet 2.0 POJOs: http://java.net/projects/sipservlet-spec/lists/jsr359-experts/archive/2013-02/message/41

MMIM MSRP EOF Exception

Recently, in the project MMIM, the TCP layer of MSRP module often threw an IOException (EOF Exception).  In the exception trace stack, there is without any our code, so it was not easy to find the cause.  But because this exception did not happen before, so I still believe this exception was caused by our code or something else.  One of most possible reason to cause IOException is the connection broken, and there are two kinds of connection broken, the server side broken and the client side broken.  So I tested this two scenarios, then found that if the server side to broke the connection, there is no exception, but the client to broke the connection will cause that exception.  Then I checked the client side.  Finally, I found it caused by the Tcl script to terminate MSRP Client before SIP layer sent BYE to terminate the MSRP session.

Template Method pattern in Java - Two Ways

In Java, there are two ways to implement Template Method pattern.  One is to use abstract method, another is to use anonymous inner class.  In the first way, you need to write an abstract base class.  In this abstract class, you should have at least one main public method.  This method is the main entry of your class and implement the main function.  At the same time, in this abstract class, you should add some abstract methods invoked by the main public method to make sub-classes to implement the details.

The second way is not the typical Template Method pattern.  But it can achieve the similar goal.  You can find a lot of examples from open source projects to use anonymous inner class to implement Template Method pattern.  One of famous examples is JdbcTemplate from Spring JDBC project.  In this class, the methods like execute(ConnectionCallback action) are using inner class to implement a template method.  The benefit using anonymous inner class to implement Template Method pattern is that you do not need to extends a base class.  So it is more flexible than the abstract class way.  But the con is you cannot enjoy the polymorphic type.

Java Concurrency: Thread State

In Java, a thread has 5 kinds of states: NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED. When you execute Thread.sleep(long), the current thread status will transform from RUNNABLE to TIMED_WAITING, and the current thread will give up CPU resources to another threads. But the current thread will not give up the monitor.

When execute Object.wait(), the current thread will become to WAITING state ( Object timed wait will make thread to TIMED_WAITING state ). But different with Thread.sleep(), Object.wait() will make thread to give up the monitor.

When your code use synchronized keyword try to acquire a monitor but blocked, the current thread will be at BLOCKED state. At that moment, the thread cannot respond to the interruption. But at WAITING and TIMED_WAITING state, a thread can have chance to respond to the interruption.

Different with synchronized, Lock.tryLock(long time, TimeUnit unit) can respond to the interruption. So use Lock in Java 5 concurrent is a way to avoid dead lock.