Friday, 25 November 2011

War of the Languages

It wasn’t until recently that new JVM based languages spread all around. Clojure, Scala, Ceylon and Kotlin are  the newest ones joining the rush and elderly ones are Groovy, JRuby and Jython.
Clojure and Scala are new frontiers of functional language domain, stating immutability and no state sharing like their predecessors Erlang, Haskell and Lisp.
On the other side Ceylon and Kotlin are commercially initiated languages, as a response to to Oracle’s Sun acquisition. As an IDE company Jett Brains launched its own Kotlin language, while JBoss drove Ceylon under the management of Gaving King.
Personally I can understand Ceylon and Kotlin language initiatives as they are supported by JBoss and JetBrains respectively. It is obvious that JBoss as a J2EE player does not want to depend on Oracle’s Java plans and lose market share in the long term. Same logic is valid for JetBrains as well. I suspect both companies does not want to wait for Oracle’s Java plan or to sued due to any kind of Java patent infringements.
When it comes to functional languages, I don’t think none of them will be a main stream language for another decade unless todays micro processor design does not change. It is evident everything is stateful in microprocessors, from binary calculations to signed/unsigned numbers and assembler commands. In all these cases, a state check exists. I can say that functional-program contradicts with today’s basic principles of computing.
When reviewing those new languages, I think there is a need to highlight what’s wrong with current Java, what kind of obstacles are exist? In my opinion there are some certain issues needing improvement, like nasty null checks, repetitive type casting, broken garbage collection and memory leaks in class loaders, lack of true isolated class loaders with self memory management parameters, no built-in immutable object support, no modular system to deploy applications with a small dependency footprint (JRE 1.7 size is around 19mb).
To be honest, I don’t think Java will die soon due to those aforementioned issues, it is also clear that new emerging languages are not completely addressing today’s software development problems. I think we are in a corner stone that “one size fits all” doesn’t work any more. It’s high likely there are going to be software systems including components developed by different languages. For example a front end web application might be java based while a backend pricing/exchange application can be built onto Erlang/Scala to benefit from native immutability/messaging support.
I would like to see picking right tool for the job, instead of pushing one tool for everything approach. I imagine neither Java nor any of those aforementioned languages will address today’s software development issues alone, instead they will live in the same ecosystem altogether.

Monday, 21 November 2011

My initial rabbitmq experiment

Last weekend I wanted to spend some time on messaging software available as open source, did some investigations and found a couple of messaging products. I noticed that most of products generally implemented JMS, including Apache ActiveMQ, Jboss Hornet, but RabbitMQ was an exception. It was completely different than those JMS implementations from ground.
First of all, rabbitmq development is focused on a wiring protocol called Advanced Messaging Queing Protocol (AMQP) instead of JMS. To achieve high performance requirements rabbitmq is built on Erlang language. Erlang itself is a functional, interpreted language concentrated on reliability, clustering and immutability of messages. It is not surprising to see guys at rabbitmq made good decision by choosing Erlang as development language of rabbitmq.
As messaging platforms require very low latency figures and clustering, it would not be reasonable to see Java for such a messaging platform. By design Java itself is not a functional language and immutability of objects requires a lot effort, not to mention that Erlang comes with Open Telecom Platform (OTP) tools, which provides a bunch of tools for clustering, distributed communication and database management .
After spending some time on comparison of messaging products and reading reviews. I decided to try rabbitmq on my Windows laptop. I followed rabbitmq windows installation guide, which directed me to Erlang binaries download page, followed Erlang instructions to setup an Erlang environment.
Having Erlang and rabbitmq installed, I tried to use rabbitmq web based management plug-in after invoking rabbitmq-plugins enable rabbitmq_management command at command prompt. Unfortunately for some reason web admin console did not run. Later I decided to use Windows zip distribution instead of Windows service binaries and after downloading and extraction them to C:\BF\rabbitmq_server-2.7.0 folder, I followed well documented rabbitmq configuration guideline and created RABBITMQ_BASE environment variable pointing to C:\BF\rabbitmq_server-2.7.0\RABBITMQ_BASE.
Finally I was able to run rabbitmq via sbin/rabbitmq-server command and see web console screen at http://localhost:55672/#/ with default authentication pair guest/guest provided.
To summarize, my initial rabbitmq impression was good, RabbitMQ is well documented, there are plenty of screencasts, videos and tutorials to accelerate rabbitmq learning curve. It is also worth mentioning that it achieves a high performance throughput and high availability  thanks to underlying Erlang runtime.

RabbitMQ Environment Variable
RabbitMQ Environment Variable
RabbitMQ startup console
RabbitMQ Startup Console
RabbitMQ Web Console
RabbitMQ Web Console

Monday, 14 November 2011

Java class loader and Maven plugin

I recently spent some time to develop a maven plugin which was supposed to run keyword-data driven spread sheet tests via an internally developed testing framework. The framework was running tests as a stand-alone application and tests were executed by the framework’s class loader which was a bad practice as testing harness and test projects were mixed in the same context and there wasn’t any abstraction between them.

Ideally testing framework and test projects should be de-coupled, since test projects and the testing framework have their own individual dependency trees. When it comes to using Maven as a project build tool, it builds up a dependency tree according to its dependency mechanism, which means it could mix dependency of test projects and testing framework and create a new breed of dependency tree.

A sample view of a test project’s dependency tree.

A sample view of the testing framework’s dependency tree

When classloaders and dependency trees are considered, I personally think Servlet containers are perfect examples of decoupling and class loaders, they have been around for decades, are proven to be best samples of class loading over the years.

For the testing framework maven-plugin development, I started to do refactoring to extract out an interface/api definition of the testing framework so that those refactored interfaces could be served as a contract between the testing framework and test projects as servlets-api serves. In fact when servlets-api is looked at in detail, it can be observed that it’s a contract between a servlet’s container and web application.

Once having a testing framework contract api, rest of the maven plugin development and class loading involved steps creating another test projects class loader, scanning test spread sheets and facades and running those facades through test projects class loader.

Test project class loader creation

private ClassLoader createTestProjectClassLoader() throws MojoExecutionException {
    List<String> testClasspathElements = null;
    try {
        testClasspathElements = this.mavenProject.getTestClasspathElements();
    } catch (DependencyResolutionRequiredException e) {
        new MojoExecutionException("Dependency resolution failed", e);

    List<URL> projectClasspathList = new ArrayList<URL>();
    for (String element : testClasspathElements) {
        File elementFile = new File(element);
        URL url;
        try {
            url = elementFile.toURI().toURL();
        } catch (MalformedURLException e) {
            throw new MojoExecutionException(element + " is an invalid classpath element", e);
    ClassLoader pluginClassLoader = getClass().getClassLoader();
    ClassLoader mavenClassLoader = pluginClassLaoder.getParent();
    ClassLoader testProjectClassLoader =
        new URLClassLoader(projectClasspathList.toArray(new URL[projectClasspathList.size()]), mavenClassLoader);
    return testProjectClassLoader;

By using different class loaders in the maven plugin for the framework initialization and spread sheet test execution, any possible jar hell issue was avoided and testing framework context and test project contexts were separated.

As a final word, I would like to emphasize that the key point of achieving different class loaders is having a concrete api/interface definition which can be served as contract between two parties.  Once a contracting interface/api is established, it can be loaded by a parent class loader which is used by both class loaders as shown in the example.