Saturday, October 1, 2011

Double Checking Locks for Singletons

I'm not going to argue the benefits of factories and singletons in this article.  The jury is in on these topics and yes, it makes sense to spend time making boiler plate code in an effort to decouple implementations from your code.

The issue with lazy loading singletons is that there are times when singletons don't behave as you expect and in my experience, this usually indicates that you may not have a singleton after all.  Consider the following code:

public class AFactory
{
    private static final Map<TYPE,ISomething> cache = 
       new HashMap<TYPE,ISomething>();
    public static ISomething getInstance(TYPE type) {
         ISomething ret = cache.get(type);
         if ( ret == null ) {
              ret = new SimpleSomething();
              cache.put(TYPE,ret);
         }
         return ret;
    }
}

The benefits of this pattern are simple.  I can now code to the interface instead of the implementation, so if I want to hijack this factory for testing, I can simply add code like:

public static void setInstance(TYPE type, ISomething imp) {
    cache.put(type,imp);
}

and then I can put a mock in the cache for testing.  Other benefits may be to open a single connection and reuse it over and over again, or whatever.

The problem with this type of pattern is that I can get into a spot where two threads might go looking for an instance of ISomething in the cache at the same time...if no instance is there, then two separate instances can get created and the last one put in the map will be persisted.  This can cause unexpected results in some cases...especially if your SimpleSomething instance has some initialization that implements a listener, or registers with a management server or some other magic.

We could avoid this simply by synchronizing the call to getInstance, but this is needless in most cases and will cause the system to slow down as threads have to wait in line to get an instance from your cache.

The solution is somewhere in the middle.  I've heard the idea referred to in a couple of ways, but I like to call it a double checking lock.  Have a look at the slight modification to the factory method:


public static ISomething getInstance(TYPE type) {
     ISomething ret = cache.get(type);
     if ( ret == null ) {
          synchronized(cache) {
              ret = cache.get(type);
              if ( ret == null ) {
                  ret = new SimpleSomething();
                  cache.put(TYPE,ret);
              }
         }
     }
     return ret;
}

By adding a synchronized block on a cache miss, and then checking again, this forces threads accessing the factory before the cache is initialized with the implementation you are looking for to synchronize and give the application time to populate the cache.  Once it is populated, no synchronization is required since subsequent calls will hit the cache for the implementation.

Wednesday, September 8, 2010

Java SSL Connections

A while back I wrote a post on how to use the apache web client to connect to an SSL server without a globally recognized certificate.  The easy way is just to import the certificate authority certificate into your cacerts file in $JAVA_HOME/jre/lib/security but in some cases you can’t do this, so I showed how I created a custom socket factory and then registered the socket factory with the Protocol class.

While trying to get an XHTML rendering library to work today, I had an issue with untrusted certificates that I needed to get working, but since the library wasn’t using the apache web client, I was a bit stuck.  As it turns out, there is much lower level you can get to to make this work:

TrustManagerFactory tmFactory = 
	TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
InputStream is = ClassLoader.getSystemResourceAsStream("my.truststore");
trustStore.load(is, "password".toCharArray());
TrustManager[] tm = tmFactory.getTrustManagers();
KeyManagerFactory kmFactory = 
	KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
KeyStore keyStore = KeyStore.getInstance("pkcs12");
InputStream kis = ClassLoader.getSystemResourceAsStream("keystore.p12");
keyStore.load(kis, "password".toCharArray());
KeyManager[] km = kmFactory.getKeyManagers();
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(km, tm, null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

I like this way a lot better because it uses classes only from the javax.net.ssl package and work perfectly for all java based network connections.  All you have to do is create your keystore/truststore files and make them available to this code somewhere in the classpath.

Friday, June 18, 2010

Mocking Frameworks – Mockito

In order to do any kind of useful testing, you always have to make the odd Simulator or Mock object so that you don’t have to worry about the dependencies that are needed by the particular component you are trying to test.  As long as you take the time to build your code using best practices, you should be able to put your mock object in place during the test without having to change your code for deployment.  I typically use Factory classes to help me do this, but there are other patterns that you can use just as effectively.  A good rule of thumb is to always code to the interface and avoid using the ‘new’ keyword for your implementations in classes that you need to test.  A simple way to do this might be:

public final Class SomeThing {
  private SomeThing() {}
  private static ISomeThing instance;
  public static ISomeThing getInstance() {
    if ( instance == null ) {
      instance = new SpecificSomeThing();
    }
    return instance;
  }
  public static void setInstance(ISomeThing someThing) {
    instance = something;
  }
}

When I want to use an instance of ISomeThing, I just call:

final ISomeThing someThing = SomeThing.getInstance();

Assuming that you are comfortable with this idea, you’ve now decoupled your dependency ISomeThing from your code and now you can test whatever calls an ISomeThing without having to manipulate the world that your dependant ISomeThing lives in…you can simply Mock it.


Lets assume that your ISomeThing looks like this:

public interface ISomeThing {
  boolean isTheAnswer(int answer);
}

To create a Mock implementation of ISomeThing, you could create something like this:

public class MockSomeThing implements ISomeThing {
   public boolean isTheAnswer(int answer) {
      return answer == 64;
   }
}

So now before you test, you just make your factory return your Mock object instead of the regular implementation of the object.

SomeThing.setInstance(new MockSomeThing());

What will happen is that when your class uses the ISomeThing instance declared in the code by the factory class, it will return true if it is supplied with the input of 64, otherwise it will return false…(hitch-hiker metaphor intended)

public void testMock() {
  SomeThing.setInstance(new MockSomeThing());
  final ISomeThing s = SomeThing.getInstance();
  
  assertTrue(s.isTheAnswer(64));
  assertFalse(s.isTheAnswer(99));
}

The only issue is that now I have a really useless class in my code base that tells me that 64 is the answer.  If I use a mocking framework  I could do this without actually creating a mock implementation:

import static org.mockito.Mockito.*;
public void testMock(){
  final ISomeThing s = mock(ISomeThing.class);
  when(s.isTheAnswer(64)).thenReturn(true);
  assertTrue(s.isTheAnswer(64));
  assertFalse(s.isTheAnswer(99));
}

This gives me the behavior I need without actually implementing the interface.  Clean and simple.

Wednesday, June 16, 2010

How to avoid Design – The ‘*.common.util’ package

I’ve seen a lot of code that makes use of a ‘util’ package; in a limited domain, I guess I don’t really have an issue with this.  A utility package would likely contain some static classes that do things like parsing strings, formatting, sorting, certain calculations…the list is endless.  There are just some things that need to be static and available and rather than think about design, we pop it into a class called ‘StringFormatUtils’ and pop it into the util package so that we can remember to look for it in six month’s time.

The fatal flaw here is that looking for some obscure little function that worked once among a sea of formatters and parsers is just not going to happen.  Instead what is likely to happen is that the next developer that needs the function will create another version of the function and pop it into that or another utility package and eventually you end up with an unmanageable pile of odds and ends in the code base.

Instead, the developer needs to take the time to think about the problem they are trying to solve from an abstract point of view.  What is it that you are trying to do? Never mind how you intend to do it.  If you are parsing data, think about a parsing architecture, ignore the details initially and then see if you have access to someone else’s wheel that they’ve already invented.  Moving from how to what is the way to re-use code.  If you need to make your own, then build it in the abstract and put it in its own domain that can be expanded and re-used.

I vote for a complete ban on any package named ‘util’ in favor of software that is written for a specific problem domain.  If you have static analysis in your build process, I recommend a rule to root it out and eliminate it…you’ll have cleaner code.

Wednesday, January 6, 2010

Oracle’s Strange way of Dealing with LOB’s

A LOB is a database term for a data type that is very big; a Large Object so to speak.  There are times when you want to create a record that has one of these LOBs but for some reason, Oracle has some strange limitations when it comes to the size of one of these objects when you ‘insert’ them into the database.

For JDBC calls it looks like there is a max of 4Kbytes.  If your insert will never be bigger than this, then stop reading, you’re fine.  You can get around this limitation by using PL/SQL (wrap your insert in a BEGIN INSERT…; END;) as long as you don’t need to insert anything greater than 32Kbytes.

If you need to go higher than this, you need to do something a little strange.

Basically you need to insert a blank LOB into the record, then select the record for update and then write your data to the LOB you selected.  Here’s how it goes.

InputStream is = new ByteArrayInputStream("hello world".getBytes());
PreparedStatement insert = 
   conn.prepareStatement(
      "INSERT INTO test_table (id, data) values (?, empty_blob())");
insert.setLong(1, 1L);
insert.execute();
insert.close();
PreparedStatement select = 
   conn.prepareStatement(
      "SELECT * FROM test_table WHERE id = ? FOR UPDATE");
select.setLong(1, 1L);
ResultSet rs = select.executeQuery();
rs.next();
Blob blob = rs.getBlob("data");
OutputStream os = blob.setBinaryStream(0L);
byte[] buf = new byte[1024];
int len = 0;
while ((len = is.read()) > 0)
{
	os.write(buf, 0, len);
}
is.close();
os.flush();
os.close();
select.close();

Not a whole lot of fun, but it gets the job done.  I managed to find a way to get it done in a single statement but it requires PL/SQL

InputStream is = new ByteArrayInputStream("hello world".getBytes());
CallableStatement insert = 
   conn.prepareCall(
      "BEGIN 
         INSERT INTO test_table (id, data) values (?, empty_blob()) 
         RETURNING data INTO ?; 
       END;");
insert.registerOutParameter(2, Types.BLOB);
insert.setLong(1, 1L);
insert.execute();
Blob blob = insert.getBlob(2);
OutputStream os = blob.setBinaryStream(0L);
byte[] buf = new byte[1024];
int len = 0;
while ((len = is.read()) > 0)
{
	os.write(buf, 0, len);
}
is.close();
os.flush();
os.close();
insert.close();

Thursday, October 22, 2009

VarArgs in Java 5

I know this has been around for a while.  I’ve seen it, but didn’t really know what it was.  Turns out its a short hand for using arrays as an argument to a method.

If you are creating a method that takes variable arguments, it is common to supply the arguments in some sort of array.  Take for instance the MessageFormat type classes:

MessageFormat.format(String format, Object[] args);

In order to use this method, the caller would have to make the call something like:

MessageFormat.format(“Hello {0}, isn’t life {1}”, new Object[]{“world”,”swell”});

VarArgs allows you to shorthand this by declaring your method like:

MessageFormat.format(String format, Object… args);

Which can then be called like:

MessageFormat.format(“Hello {0}, isn’t life {1}”, “world”, “swell”);

The only stipulation is that your vararg argument is the last in the parameter list.  Java then autoboxes your arguments into an Object array for you.

Nice!

Thursday, August 20, 2009

Why Test Driven Bug Fixing is Better #tdd #struts

Its often difficult to convince developers that aren’t doing Test Driven Development (TDD) that its worth the little bit of extra effort to write failing tests first before touching the code.  Most times, the dissenters complain about tight timelines and lack of end user benefit to ‘be bothered’ with it.

Although I am relatively new to TDD, I’ve adopted the method in every aspect of code development I can think of…especially bug fixing.

A Case Study

This is an actual example where I used TDD to fix a bug (the names have been changed to protect the ..um.. innocent).

QA reports a bug in newly developed software.  In this case, the application is a struts web application and there is a radio button on a form that doesn’t have a default set; the analyst believes that it should be set to value ‘x’ by default.

The radio button is backed by a form bean class with the property ‘theRadioOption’ in the class MyFormBean which is scoped to the request for the struts action in question.

public class MyFormBean extends ActionForm
{
	private string theRadioOption;
	public String getTheRadioOption(){
		return theRadioOption;
	}
	public void setTheRadioOption(String value){
		theRadioOption = value;
	}
}

Given this snapshot of information, many experienced struts developers would say “OK, so I’ll go and set the default value in the bean…its one line of code, no need for a test.”


Before touching the code however, I created a test by extending MockStrutsTestCase and coded a very simple test:

public class FormActionTest extends MockStrutsTestCase
{
	public void testFormDefaults()
	{
		setRequestPathInfo("/GetForm.do");
		actionPerform();
		final MyFormBean form = (MyFormBean) getActionForm();
		assertEquals("Wrong Default","x", form.getTheRadioOption());
	}
}

Running the test, of course, it fails…perfect…now to fix the code.

private string theRadioOption = "x";

There, that was easy, now before we build the application and deploy the thing, I run the test again to see if it indeed passes.  Surprisingly, it fails…so much for my “one line of code.”


Upon further examination, I looked in the action class that forwards to the web page.  What I found was that the developer that made the form was explicitly clearing the values in the form by setting the property to null.  My little ‘fix’ wasn’t seeing the light of day because the action was ‘undoing’ my default.

public ActionForward execute(ActionMapping mapping, ActionForm form, ...etc){
	final MyActionform myForm = (MyActionForm) form;
	form.setTheRadioOption(null);
	return mapping.findForward("SHOWFORM");
}

The real fix is to get rid of the explicit set to null in the action class or set it to the desired default instead of null.  After setting the default in the action and running my test again I can then see that the test passes.


This test becomes part of the project now and is run during the build process every night…the issue will never return undetected.  How much time did I save here?  Developer builds and deploys only once instead of two or three times, QA didn’t have to re-open the bug and therefore test the feature three times instead of two, the next developer didn’t have to ask “what should this be set to by default anyway” since it is well documented in the test.


My question is how can you justify NOT putting in the little extra effort to do Test Driven Bug Fixing?