Dependency Injection Part II: Arguments For Dependency Injection

Before we dig in too deeply to Dependency Injection (DI), we need to ask an important question: Should we even be doing this in the first place?

There are arguments for and against using DI and DI containers, and considerations of when to use it versus when not to use it. This post will deal with the advertised advantages of DI. In the spirit of objectivity, some disadvantages and consideration of them will be in a follow-up post.

There are four main advantages I will be dealing with here:

1. Link using class to an interface rather than an implementation
2. Facilitate testable code
3. Manage scoping rules for your object graph
4. Reduce boilerplate code

Instantiating members inside a parent class permanently links the parent class to an implementation instead of an interface. Now one might counter that when declaring a member, assigning an implementation to an interface keeps the parent class from being linked to the member’s implementation. However, the parent class itself still depends knowing that the concrete class exists to assign the member. If this assignment is made in 100 different classes and you want to change the signature of the implementation’s constructor, you will quickly find that parent class really is tied to the implementation instead of the interface.

Injecting dependencies facilitates testable code because small portions of your application are easy to instantiate. You can instantiate the subject under test directly, specify mock objects or stubs for its dependencies (things that are not easy to instantiate, or things that have side effects like network calls or database calls) and unit test to your heart’s content! When the dependencies are hard-wired inside the subject under test, testing like this becomes impossible and you are reduced to integration tests, or worse, manual tests. The advantages of unit testing are left for another blog entry...

The DI Container can easily manage complex scoping rules. If you have portions of your application’s object hierarchy that need to be instantiated only for certain scopes (say, for a single request, or one per thread - request scope and thread scope) the DI container will manage the instantiations at the right time rather than your code having to manage it. Guice provides session scope, request scope and custom scopes, and Spring 3.x provides a thread scope in addition to its other scopes.

DI Containers reduce the boilerplate of setting up dependencies. You can provide a dependency to potentially many client classes rather than each client class instantiating it. This way you do not have to repeatedly write the code to do additional work that a dependency needs before it can be used (like calling setters, calling initialize methods, etc). You can also avoid writing the code to wire other dependencies that the original dependency might have. The container will provide the entire hierarchy of dependencies with the appropriate scope.

I think these four points (Link client class to an interface rather than an interface, Facilitate testable code, Manage scoping rules for your object graph, Reduce boilerplate code) are good arguments for using a DI container. In the next post we will look at arguments against using a DI container.

Dependency Injection Part I: A Basic Introduction

There has been much debate around Dependency Injection (DI). In this series I will explore dependency injection: what it is, the arguments for and against it, when to use (or not use) it, and some code samples.

First of all: What is Dependency Injection? You can read the Wikipedia article on it as well as I can, but to put it in plain english: Instead of a class instantiating its own member instances (dependencies), the dependencies are given to it. This is easiest to see with a little sample code.

// without DI
public class Parent {
  Something s = new ConcreteSomething();
}

// with DI
public class Parent {
  private Something s

  // constructor injection
  public Parent(Something t) {
     s = t;
  }

  // setter injection
  public void setSomething(Something t) {
     s = t;
  }
}

Note the two different ways of getting Something into Parent: via a constructor or setter. There are other ways to accomplish this (Martin Fowler's DI Post includes Interface Injection) but these are the techniques that I have seen used the most often. I favor constructor injection in particular because I like having the object constructed in a usable state, and think it’s good practice to make dependencies explicit. That way if the constructor argument list gets too long, it’s a good clue that your class might be trying to do too much!

Next, there is a difference between DI and an DI Container, and many people confuse the two. DI is just the design pattern, the idea of arranging classes in such a way that a dependency is given to a using class instead of the using class instantiating it. A DI container, on the other hand, is a framework that facilitates DI to the point where you can construct an entire application using dependency injection. When people argue for or against DI, they sometimes are actually arguing for or against the idea of using a DI container vs the design pattern of DI itself (or vice versa). For purposes of this blog, I will use DI to mean using a DI container to structure an entire application. Arguments revolving around this should be a superset of arguments revolving around DI as a design pattern.

Finally, some things to note about how to use DI in Java: The javax.inject package (aka, CDI or “Context and Dependency Injection) is a standard in Java EE 6, so it’s not hard to get started with using this in your own code. The related JSR’s JSR-330 and JSR-299 (which are different from each other) have various implementations available, such as Dependency Shot, Spring, and Pico. Guice 3.0 is the Reference Implementation for JSR-330. Later we will be looking at working samples using Spring and Guice.

In the next post, we’ll examine the arguments revolving around DI, and get a feel for when it is appropriate.

Running Tomcat Without Root Privileges

There are a number of security considerations for running Tomcat (indeed, for any web server). The documentation at OWASP and the Tomcat security docs do a pretty good job of outlining the major considerations.

One frequently mentioned best practice is that your web server should not be run as root and should instead be run as a non-privileged user. However, programs run with non-root privileges can’t bind to lower standard ports (below 1024), and we would generally like to serve our site on the standard ports (like 80 and 443).

Since tomcat should be run without elevated privileges, and access to port 80 requires elevated privileges, we need to resolve this issue. There's no single best way per se on how to do this, you need to understand the options and make the most suitable choice for your situation.

Here are some options arranged (in my opinion) by ease of use, with caveats as sub-points. Note that this presumes Tomcat on Linux.

• Use authbind to enable a non root user to bind to ports below 1024. This solves the problem very directly and it is available on Ubuntu with sudo apt-get install authbind.
• Caveat: Available only on debian linuxes
• Caveat: Doesn’t work with ipv6
• Use firewall software on the host to configure port forwarding.
• Run Tomcat as root, but in a chroot jail
• Use setcap to set capabilities
• Caveat: Doesn’t work if starting from a script (starting with #!)
• Caveat: JDK 1.6 did not work when using capabilities, but it works with JDK 1.7
• Use Apache running on port 80 and AJP to send requests to Tomcat. Using Apache would probably be a better choice if you have other reasons for choosing it like serving static content or load balancing.
• Caveat: need to set up Apache if you haven’t already
• Caveat: with virtual hosts that share an ip address you need to set up SNI (which might not have a full browser support)
• Port forwarding with iptables
• Caveat: NAT is not supported in ip6tables (IPv6 version of iptables)

Propagating Best Practices in Code

Recently during a code review, I mentioned to my colleague that a certain method could be eliminated by just implementing the appropriate marker interface so our framework would run the equivalent code at the right time. Not having encountered that technique, he appreciated the comment and said “Is there an easier way to learn about what's available rather than through code reviews?” Good question.

I’ve noticed that within the context of a particular codebase, there are accepted best practices. In the previous example, the best practice was knowing what your codebase or framework already provided vs what you needed to write, but there are other examples such as which classes should begin transactions, how to get a database session, and using programmatic transactions vs declarative transactions.

As a software product is developed, the team develops a standard for how to accomplish particular things in code. But you know what they say: the nice thing about standards is that there are so many to choose from.

On a large project (say, 1+ million LOC) I’ve found that often one practice in code is improved or modified resulting in two ways of doing something (since the previous technique is not removed). This can happen again and again, resulting in multiple practices in the code. When someone who’s not familiar with that practice looks for examples, it becomes impossible to tell which is the “best” or “accepted” way to do something.

At first I thought of this as a refactoring problem. If only we had enough code reviews, such cases would be caught and older duplicate techniques would eventually be refactored away, right? But I think the issue is more general than that, that this is actually a case of methodological organizational knowledge being lost. People change jobs, people unknowingly duplicate effort, and with a large codebase it becomes difficult to propagate every practice or know what every other person is doing.

This raises some questions: How do we build up best practices or established ways of doing things in the code? If we want to update a practice, should we fix the old practice incrementally as we see it, or migrate it all at once?

For the first question: knowledge management is a well-known process. In the context of software development, I imagine that spreading knowledge would ideally include a variety of communication techniques such as code reviews, learning sessions, mentoring, and pair programming. Last on the list (but still on the list) would be documentation, since developers generally look to code for examples rather than static documentation.

For the second question, note that developers generally reference the code rather than static documentation. If we try to slowly migrate one practice to another, there is a danger of developers propagating the old practice. That is an argument for refactoring a practice all at once, but depending on the scope of that change it could carry significant cost and risk (that the old practice covered a case not covered by the new practice). So there is a balance to be had between incremental updates to a practice and migrating a practice all at once. To make the decision on that balance, I would say that if the refactoring is small enough to be accomplished in, say, a single sprint, then it’s worth it to refactor. Beyond that, the cost and risk may be too high. Such a change should be accomplished incrementally by changing the old practice as you come across it, and by noting this as a larger task in your backlog.

And hey, maybe sharing knowledge would best be done with tweets! "Hey I just started using ActiveButton instead of HoverableButton, you should use it too". Wait, that’s too many characters, it should be more lolcatz. "yo dawg i jus strted usin ActiveButton FTW! u shld use it 2! OMGLOL”

Lambdas: Coming to JDK8 Soon!

It's exciting to see lambdas finally making it into Java after so long! I was excited to learn about it, so I whipped up some sample code and am doing a presentation on JDK8 Lambdas for some other developers.

One caveat: As I write this, the lambda API is still under development, and it's tricky to learn an API and write samples that work when the API changes from day to day. When I migrated from JDK8 dev build 64 to build 69, classes had been renamed and methods had moved or disappeared. The presentation here uses lambda build 69, and the code samples in the presentation are fully functional but will undoubtedly be out of date when the lambda API is finalized.

Be that as it may, it's exciting to learn a completely new way of doing things, especially in Java. You can check out my presentation for all the details, but the critical resources might be nice to have available here:

• JDK8 dev build for lambda (different from "regular" JDK8 as of December 2012)
• State of the Lambda (whence came most of this presentation)
• Javadocs
• Lambda Faq
• Mailing List

Uploading Binary Files the Fun Way

Here’s the problem: suppose you have a domain object (say, an item) which can be created restfully by posting json data in a request body. Spring can automagically convert request bodies in json to Java objects on the server, which is incredibly convenient. It’s also an incredible pain in the butt if you have a new requirement to upload the contents of a binary file as part of that json object (say, an item image to be stored on the server and displayed later).

Fortunately, there’s a fun way to include binary file content in your json object!

Here are the Java objects we’ll be dealing with. Note that the Image class has a byte[]: this will be coming from an image file from the browser, stored in the DB, and streamed back as needed upon request.

@Entity
public class Item {

  @OneToOne
  private Image image = null;

  ...
}

@Entity
public class Image {

  @Lob
  private byte[] bytes = null;

  @Basic
  private String contentType = null;

  ...
}


Next, on the browser we can make use of the file API to load a file, then encode its contents using Base64 encoding, and finally assign the encoded contents to our javascript object before posting it.

function put() {

  // get a file object, we only need one
  var file = $('input[type="file"]').get(0).files[0];

  // obtain the object you want to post as a json object
  // in the body of a POST
  var item = ...

  if(file) {

  var reader = new FileReader();

  // after the file has loaded on the client,
  // convert to base64 and assign to the item before POSTing
reader.onload = function loaded(evt) {
       item.image={};
       item.image.bytes = arrayBufferToBase64(evt.target.result);
       item.image.contentType = file.type;

       // post json object as the request body
       // with the technique of your choice
       // I like using $.ajax(...)
       create(item);
  };

  reader.readAsArrayBuffer(file);
  }
  else {
  create(item);
  }
}

// pass in an HTML5 ArrayBuffer, returns a base64 encoded string
function arrayBufferToBase64( arrayBuffer ) {
  var bytes = new Uint8Array( arrayBuffer );
  var len = bytes.byteLength;
  var binary = '';
  for (var i = 0; i < len; i++) {
  binary += String.fromCharCode( bytes[ i ] );
  }
  return window.btoa( binary );
}


Now on the server, we have a Spring Controller which will handle the request. As part of the json unmarshalling that converts the the request body to an Item, the base64-encoded value in image.item.bytes will be converted to a standard Java byte[], and stored as a LOB in the database.

@RequestMapping(value = BASE_URL + "/item", method = RequestMethod.POST)
public @ResponseBody long createItem(@RequestBody Item incoming)
{
  // authorization and input scrubbing removed for brevity

  service.createItem(incomingItem); // sets the itemId
  long newItemId = incoming.getId();
  return newItemId;
}


To retrieve the image, another Spring Controller method can provide the image by streaming the bytes directly.

@RequestMapping(value=BASE_URL + "/item/{id}/image", method=RequestMethod.GET)
public void getItemImage(@PathVariable Long id, HttpServletResponse response) throws IOException
{
  Item item = service.loadItem(id);
  response.setContentType(item.getImage().getContentType());
  response.getOutputStream().write(item.getImage().getBytes());

  // don't close the output stream from the response
}


Now if you need to retrieve the image, you can simply reference the item’s id in the appropriate URL in an image tag: <img src="... /item/image/1/image" />

Beautiful!

Unit Tests and Transactions

A question came up on StackOverflow recently that got me to thinking about how to unit test transaction-dependent behavior.

Generally we start with data access tests that are transactional so that each test can roll back when it's complete. This way each test can modify an in-memory database without affecting subsequent tests. 

Let's say we are tasked with writing code for a common workflow in our application that loads, updates, and saves an entity. We might write a test like this that hits a live in-memory database:

// everything is in one transaction
@Transactional
public void test() {
  String newValue = "somethingnew";
  Entity t1 = dao.getById(id);
  t1.setProperty(newValue);
  dao.update(t1);
  Entity t2 = dao.getById(id);
  assertEquals(newValue, t2.getProperty());
}

We then write code to make the test pass, and move on believing that All Is Good. But all is Not Quite Good.

Imagine that something is wrong with our dao.update() method and it actually does not update the database.

1. In that case, the object t1 is stored in the current database session
2. Retrieving t2 by id actually returns t1 by virtue of being called in the same transaction
3. The test compares t1 with its own property, instead of comparing the new value with the persisted value
4. The test passes but should have failed.

One way around this is to remove the transactional boundaries from the test method and allow the methods we're testing to begin/commit their own transactions (which they will normally be doing anyway). This way if the update method does not update the entity, the bug will quickly be exposed and All Is Good again.

// test method is not @Transactional

// DAO methods are themselves @Transactional

public void test() {

  String newValue = "somethingnew";

  Entity t1 = dao.getById(id);    // transaction 1

  t1.setProperty(newValue);

  dao.update(t1);                 // transaction 2

  Entity t2 = dao.getById(id);    // transaction 3

  assertEquals(newValue, t2.getProperty());

}

One thing to be aware of with the second test is that if we are committing against an in-memory database like HSQLDB, our changes made in one test will not be automatically rolled back, and will be visible to subsequent tests. We will have to manually undo all of the changes at the end of the test, or ensure that the test data does not interfere with other tests which is not so easy.

In summary: when would we use one kind of test vs the other? In general I think the benefits outweigh the risks for rolling back after each test, so that is usually my starting point. Testing a workflow that crosses multiple transactions is really a job for an integration test and can easily be done with Selenium or SoapUI. So I would favor a full integration test to test that kind of behavior, and use a multi-transactional unit test to experiment with a new sequence of calls or debug a certain scenario quickly and without the overhead of a full integration test. 

What do you think? Do you favor multiple or single transaction tests? Have you seen the transaction test bug described here?