WSDL versioning

A few weeks ago I was asked how to version WSDLs. Well I had no idea, as I have never needed to do that. I worked in tightly environment where new versions of consumers and publishers were deployed at the same time. Sometimes not very successfully, but we didn't need to support multiple versions.
  I found the problem of WSDL interesting so I start googling and here are some information I found. The WSDL doesn't support versioning, so there are couple of ways how to do it.

• Including service version in URI
• Versioning using namespace (more information can be found here)
• Using UDDI (more can be found here)

 I personally prefer versioning using namespace.

Correct singleton implementation

This is a bit outdated problem, but for my easy reference and for those who haven't stumbled on this problem I decided to write short article about correct singleton implementation. Much longer and descriptive article can be found here.
   It is quite common to see singleton implementation like this:

public class DBConnection {

    private static DBConnection instance;
    
    private DBConnection() {
        //DO something
    }
    
    public static final DBConnection getInstance() {
        
        if (instance == null) {
            instance = new DBConnection();
        }
        
        return instance;
    }    
}

Unfortunately this code doesn't work in multi threaded environment. Sometimes people try to fix it with following code:

public static final DBConnection getInstance() {
        
        if (instance == null) {
            synchronized (instance) {
                instance = new DBConnection();
            }
        }
        
        return instance;
}

This also doesn't work, due to Java memory model. There are some thread safe implementation, which actually differ between Java 1.4 and 1.5 up. For Java 1.4 the correct (lazy) implementation is:

public class DBConnection {

    private static class DBConnectionHelper {
        static DBConnection instance = new DBConnection();
    }
    
    private DBConnection() {
        //DO something
    }
    
    public static final DBConnection getInstance() {
        return DBConnectionHelper.instance;
    }    
}

Non lazy implementation for Java 1.4:

public class DBConnection {

    private static DBConnection instance = 
                           new DBConnection();
    
    private DBConnection() {
        //DO something
    }
    
    public static final DBConnection getInstance() {
        return instance;
    }    
}

From Java 1.5 up, there is available other implementation:

public class DBConnection {

    private static volatile DBConnection instance = null;
    
    private DBConnection() {
        //DO something
    }
    
    public static final DBConnection getInstance() {
        if (instance == null) {
            synchronized (this) {
                if (instance == null) {
                    instance = new DBConnection();
                }
                
            }
        }
        return instance;
    }    
}

And from Java 1.5 singletons can be implemented using enum:

public enum DBConnection {

    instance;
    
    private DBConnection() {
        //DO something
    }    
}

The instance is then accessible following way:

DBConnection connection = DBConnection.instance;

Why I like Java in Groovy

For many people the option in Groovy to switch to Java seems useless and as an extra burden. But I find it very useful, with great potential (just like option to inline assembler in C or Pascal, in the good old days). And I have an example where I can show you how I used it in real life.
   Because for the past year I was responsible for our builds, I wrote some scripts to simplify the tedious and error prone work. First I wrote some bash and Ant scripts, which I latter ported to Gradle. I found Gradle to be more suitable for the tasks our build required.
   Recently I was writing a task to manipulate some binary files, when I run into an odd problem with Gradle/Groovy. With following implementation:


// wrong implementation
File inputFile = new File("location.tmp");
locationTemplate = inputFile.getText();
byte[] tmplContent = locationTemplate.getBytes();
byte[] resultContent = new byte[ tmplContent.length];
//do something with the content and copy it to resultContent
f = new File(metaFilePath);
f.write(new String(resultContent));

Some bytes/characters were changed during saving, which was a problem. So I changed it to following implementation:

//working implementation
File fin = new File("location.tmp");
long length = fin.length();
byte[] tmplContent = new byte[(int)length];
FileInputStream fis = new FileInputStream(fin);
fis.read(tmplContent);
fis.close();
//do something with the content
FileOutputStream fos = new FileOutputStream(new File(metaFilePath));
fos.write(resultContent);
fos.close();

So I came to a point where I was thankful to Groovy and Gradle that I can switch seamlessly between Groovy and Java.

Pushing the Limits in Java's Random

Dr Heinz M. Kabutz, editor of Java Specialist's Newsletter, just published another fascinating article, this time about Java's Math.random(). This time with help from Dr. Wolfgang Laun, from Vienna. You can read the whole post here:

http://www.javaspecialists.eu/archive/Issue198.html

The important information is that, to get a random number from zero to some_int, we shouldn't use this code:

(int)(Math.random() * some_int)

Instead we should use nextInt(some_int) from java.util.Random class. Since Java 7, due to concurrency, we should use:

ThreadLocalRandom.current().nextInt(some_int);

But things are not so easy. There is a bug in Java 7 versions prior to 1.7.0_02, that results in returning the same value for all threads. I strongly recommend to any professional to read the whole post and also older posts from Dr. Kabutz's newsletter.

BTW: Dr Heinz M. Kabutz is a member of Java Champion group, an exclusive group of passionate Java technology and community leaders who are community-nominated and selected under a project sponsored by Oracle.

Immutable and no unit tests

This is something I came across recently in our codebase:

 public String doSomething(SomeClass inputParameter) {
  ...
  if(result != null)
    result.trim();
  return result;
}

Well as you (probably) know the method will return untrimmed result. This turned into a nasty bug found during UAT testing, which took us couple of hours to find and solve. But this type of bug could be easily found with unit tests (if written properly). This is one of the reasons why I like Test Driven Development.

The One Correct Way to do Dependency Injection

Just read nice article about dependency injection explaining why dependency should be moved to constructors, and what benefits it may bring.

The One Correct Way to do Dependency Injection

Intro

This is my first post. It is about my motivation to start this blog and what I want to publish here.

The main reason to start my own blog is to publish things I am missing on the web. This blog will be also something like my external memory, where I will put stuff that I need only occasionally and I always forget them (like some SQL or batch scripts).

Than there is motivation to practice writing and putting my knowledge under public scrutiny - so I can learn from my mistakes. This is really hard part, I admit that I am bit (actually really) worried about putting my skills under public scrutiny. For this you will find snippets from my code and some free/open source stuff I wrote.

The main theme on this blog will be software development and everything that has something to do with it. From very technical articles to articles dealing with software development management.

Why "Polyglot Programming" or "Do It Yourself Programming Languages" or "Language Oriented Programming" sucks?

Few days ago I read an interesting article about multi-programming language paradigm by Lofi Dewanto:

Why "Polyglot Programming" or "Do It Yourself Programming Languages" or "Language Oriented Programming" sucks?

I have to say that he is talking from my heart. I've been working in enterprise environment for last 8 years and have seen many enterprise systems. Supporting a system that is build on homegrown framework, made of multiple technologies, with almost no documentation and no support is not a nightmare, it is a journey through software development purgatory.