Posts Tagged ‘java’
Dependency Injection with Guice and GuiceJumper May 10, 2014 | 10:14 pm

When a lot of people discussion static vs. dynamic typing, they are really discussing Java vs. Ruby typing: they simply don’t know any better than to think that Java is representative of static typing. In a similar way, when people hear “dependency injection”, they think Spring. I was one of these people: after getting caught on one too many angle brackets, I was generally put off Spring. The dynamic language features of Groovy made Spring a bit more tolerable within Grails, but I still found it more annoying and obscure than helpful.

For a while, I considered dependency injection to be an informative failure, but something kept nagging at me: the magical variables in Rails are effectively involuntary dependency injection—this pattern is half-jokingly called “dependency ejection” or “dependency secretion”. So there’s something to dependency injection, even if Spring got it wrong.

Then, at JavaOne, I bumped into some of the Google devs, and they pitched me Guice. Some of the pitch points hit home: compile-time type checking; actionable error messages; configured through code; works with immutable classes. However, it still used annotations (which I was busy hating on), and dependency injection was not a popular point with me, so it took me a while to get around to checking Guice out.

I wish I hadn’t waited so long.

Guice does dependency injection as right as I’ve seen, and it makes working within Java and Groovy much nicer. Its simplicity sometimes leads people to underestimate it, however. Recently, I released GuiceJumper, which is my extension to the Guice core library. The code in there demonstrates some of the power of Guice.

For instance, there’s the ExecutorModule. Its primary purpose is to enable classes to ask for an ExecutorService—the core class for concurrency—by specifying the kind of tasks that will be passed to it. The context will provide an appropriately-configured implementation of the ExecutorService, which (if appropriate) is shared throughout the system.

// Groovy code so it's short enough to read
class Busy {
   @Inject @Background ExecutorService executor
def injector = Guice.createInjector(new ConcurrentModule())
def busy = injector.getInstance(Busy)
busy.executor.submit {-> ... }

The @Background annotation means the ExecutorService will be appropriate for background task processing. The other options are @Process (CPU-limited processing); @Read (work production and I/O input); and @Write (work consumption and I/O output).

But that’s no big deal: that’s basically a step above rudimentary dependency injection. Slightly cooler: load your application configuration up into your favorite properties file (through, say, Properties.load(Reader)), provide it to the PropertiesModule, and then those properties will be available throughout your system. You can convert them to any primitive type, BigInteger, BigDecimal, Charset, File, URL, URI, or any enum…with actionable errors if the conversion fails. So all those magic constants can now be stored up front in a single configuration step, loaded later, and you will get an early error if they are badly formatted or otherwise bogus. It’s a beautiful thing.

class Configured {
   @Inject @Named("my.config.prop") int value
   @Inject @Named("") URL blogUrl
def injector = Guice.createInjector(new PropertiesModule(["my.config.prop":"42", "": ""]))
def confed = injector.getInstance(Configured)
assert confed.value == 42
assert "$confed.blogUrl" == ""

The I18nModule pulls a similar stunt, but uses annotations that look like @Localized("i18n.key") and loads localized values from the ResourceBundle, enabling super-simpler localization of the application and centralization of the messaging.

I’ve got another module to be released which provides all the wiring necessary for the AWS Java SDK objects, but that’s not released to the public yet.

Guice gives you the ability to have a distinct configuration phase to your application, which is entirely under the control of your application, and which need not be at the very beginning. In fact, I have systems that have multiple configuration phases, generating child injectors with new modules as more information becomes available: for instance, my hybrid of Groovy/Guice/Restlet (working title: Restling) creates a new injector for each request. The request injector can provide the request itself, the response, the user, and other request-scoped information.[1] It is worth emphasizing that all of this is configured and controlled by code, which means that you can have precise control over what is going on when, and in the unlikely situation that there is a problem, you can apply your standard debugging tactics. It’s great.

It’s dependency injection without the pain. I love it.

[1] Yes, I am aware that there is a request scope using the servlet plugin for Guice. I find that plugin more magical than helpful, especially given that I can accomplish the same things with nested injectors.

Executing a MySQL Script through JDBC July 30, 2013 | 03:26 pm

There’s no way to execute a MySQL script through JDBC, and most of the tools (including SimpleJdbcTestUtils) have weird requirements for the script and/or a bunch of overhead to do what you want to do. The big trick is that DELIMITER isn’t actually a SQL command: it’s a pre-processing instruction (at least conceptually). And that makes feeding the script into MySQL a pain.

Groovy and Commons-Lang StringUtils to the rescue. Here’s the short script that will break up a SQL script into a Collection of String objects, which can then be fed to your favorite SQL execution tool.

	static Collection<String> breakUpSqlScript(String loadSql) {
		List<String> statements = []
		String delimiter = ";"
		String currentStatement = ""
		loadSql.eachLine { String line ->
			line = line.trim()
			if(StringUtils.startsWithIgnoreCase(line, "--")) {
				// Comment: IGNORE
			} else if(line.endsWith(delimiter)) {
				line = StringUtils.removeEnd(line, delimiter)
				currentStatement = "$currentStatement \n $line".trim()
				statements << currentStatement
				currentStatement = ""
			} else if(StringUtils.startsWithIgnoreCase(line, "DELIMITER")) {
				delimiter = StringUtils.removeStartIgnoreCase(line, "DELIMITER").trim()
			} else {
				currentStatement = "$currentStatement \n $line"
		if(!StringUtils.isBlank(currentStatement)) statements << currentStatement
		return statements

PS: If you want to get the contents of a file as a string, use File#getText().

Open Source Announcement: CleanSweep March 26, 2013 | 10:22 am

I just knocked out a generic implementation of a sweeper that leverages Java’s concurrency structures to provide a very pluggable background replacement for finalize(), which we all know is evil. It also works well for caching. You can find it over on GitHub under the name RobertFischer/CleanSweep. Instructions on its use are there, but it basically looks like this:

import com.smokejumperit.cleanSweep.Sweeper;
/* [...] */
    final Sweeper sweeper = new Sweeper();
/* [...] */
    Object it = new Object();
    sweeper.onGC(it, new Runnable() {
      public void run() {
        System.out.println("onGC action run!");

I Don’t Get It February 5, 2010 | 03:29 pm

When encountering a bug in an open source project, most Java people seem unwilling to either fix it themselves or pay the maintainer to fix it—they’d rather abandon the project or kludge their software painfully and repetitively. WTF?

Java Posse, .Equals(), Inheritance, and the Liskov Substitution Principle October 29, 2007 | 06:38 am

Continuing the conversation had by Raganwald, me, and a lot of the rest of the blogosphere:

The Java Posse Responds to My #Equals Issue
(If you don’t know the Java Posse, check out their website/blog/podcast. It’s good stuff.)

The answer they gave was an interesting one, which I’m still sitting on and working in my head. Here is Martin OConnor’s response, for those too lazy to read the (very interesting) thread:

Your class hierarchy is flawed. ThreeDeePoint does not naturally extend TwoDeePoint, because a Three Dimiensional point is not a kind of Two Dimensional point. They represent two very distinct concepts. Essentially, when you extend TwoDeePoint with ThreeDeePoint, you are saying that ThreeDeePoint is a special kind of TwoDeePoint. I would submit, therefore that the problems you are observing are less due to the impelmentation of Object.equals(), and more as a result of your chosen class hierarchy design.
What I was trying to explain, (although poorly), or more precisely hinting at, is The Liskov Substitution Principle. This is an Object Oriented design principle that states that any reference to a base class should be replaceable with a reference to a derived class without affecting functionality. What my previous post had attempted to say is that since the TwoDeePoint and ThreeDeePoint classes do not adhere to The Liskov Substitution Principle, the design, in this particular case is flawed.

(For those that don’t remember my “TwoDeePoint” and “ThreeDeePoint” example, check my post, “A Java Gotcha”, where I first get into the #equals/#compareTo issue.)

So, is it invalid for a 3DPoint to inherit from a 2DPoint? The general way this is phrased is “is it legitimate to say 3DPoint is-a 2DPoint”? Well, that depends on what your definition of “is-a” is.

After all, the semantics behind a 3DPoint imply it is a 2DPoint, as it has all the same qualities of a 2DPoint: it simply adds the idea of a third dimension to the existing definition. Semantically, a three dimensional point is a two dimensional point residing on a particular point in the three-dimensional axis, and it has all the capabilities of a two dimensional point on that particular plane.

On the other hand, the Liskov Substitution Principle gives a much stricter definition of “is-a”. I’d like to look at a colloquial definition of the principle, and then a formal definition, because there is a huge gulf between these things.

Colloquially, it basically says that Foo should not inherit from Bar unless Foo is-a-specialization-of Bar: that is, Foo is a limitation upon Bar. So the inheritance in that example is invalid: 3DPoint is not taking 2DPoint and limiting it, but it’s taking 2DPoint and extending it.

Adopting this approach to inheritance will substantially limit its use, and is going to lead to some repetitive code — in my example, all the 2DPoint methods would have to be re-implemented as 3DPoint methods. But it does side-step the #equals/#compareTo problem, in that a specialization will have to rely on the same #equals/#compareTo definition as its parent class.

And that’s where the rub is. Using the cite by way of Wikipedia, let’s look at the formal definition of this principle:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

My rub is with the phrase “a property provable about”. Consider a type of a matrix (M) and a diagonally symmetrical matrix (S). Specifically, there exists M#setXY that sets the item at [X,Y] to a vaue. In S#setXY, we override it so that it also sets the item at [Y,X] to the same value as [X,Y] was set to (thereby maintaining symmetry). Now, S is a colloquial specialization of M, but it could be a violation of the substution principle, since it changes the postcondition of M#setXY: is the fact that the rest of the matrix remains unchanged in M#setXY constitute “a provable property”?

Assuming that “a provable property” is basically analogous to the precondition/postcondition properties, I suppose there is no reason that M#setXY has to specify that the rest of the matrix remains unchanged. What we would basically be arguing in this case is a very liberal interpretation of the role of preconditions/postconditions: the postconditions of M#setXY need not specify everything that M#setXY does, and the preconditions of M#setXY might not need be all true.

If this is the case, then calling a method becomes a very, very scary thing. It is now legitimate for me to implement M#setXY to set every item in the matrix to NaN, delete your hard drive, send out 3000 spam mails a second, and make some coffee. As long as M#setXY ends by setting [X,Y] to the given value, it is an acceptable implementation of inheritance.

So, if we deny this liberal interpretation, and then S is not a legitimate case for inheritance of M, because S#setXY does something which M#setXY doesn’t specify. So the specialization we’re talking about by way of the substitution princple is extremely limiting: basically, all you can do is throw a different sub-class of already-declared exceptions, return subclasses of already-declared return values, and add methods which do not intersect/interefere with the provable properties of any other method, including #equals/#compareTo.

This limits inheritance to very few cases. Certainly, the implementations of abstract class are allowed, assuming that the abstract class leaves enough breathing room (e.g. vague enough declared exceptions) for an underlying implementation. This can be seen, for instance, in Java’s AbstractCollection. Anything which tacks on a piece of non-identifying information or non-interfering functionality works just fine, too, although I’m having trouble coming up with a good example for either of those.

Some people older and wiser than me once asserted that no inheritance should be done on anything other than classes explicitly defined for inheritance (i.e. abstract classes). At the time, I thought that was extreme, and so I discounted the position. I’m increasingly starting to understand it, though, and I think I may be signing on.

Commons-Lang and the equals()/compareTo() Debacle January 30, 2006 | 10:22 am

Like most traumatic realizations, I’ve been having trouble getting the fundamental equals/compareTo brokeness of Java out of my head.

I decided to take a look at the Commons-Lang library to see how they deal with it. They’ve got a class called EqualsBuilder which is supposed to take care of this stuff for you. So I was wondering how it did that.

It gives you two options:

  1. Reflection
  2. Manual

The manual process has all the problems that I’ve talked about here and here, so we’re going to punt on that.

For the manual process, if that was the way it was decided to go, my deisgn would be a bit different. First and foremost, the isEquals private member variable should really be a constant.

I would go a step further and make there be only two instances of an EqualsBuilder: the one where it’s not false yet, and the one where it’s been determined to be false. These two could be implemented as private inner classes implementing the common abstract base class, so the one where it’s been determined to be false literally does no work and the one where it’s not false yet contains all the tricky thinking code. That’d save some branching and a lot of object burn. Of course, that’s arranging the deck chairs on the Titanic, so let’s not spend any more time there.

The reflection option has much more promise. It (in its most precise form) accepts the following information:

  1. Two objects to compare
  2. Whether or not to test transients
  3. Class to test up to

I’m not entirely sure about the value of the class to test up to, because the scenarios where that’s anything other than “Object” seem to be making some really strong assumptions about the internal behavior of the code. Similarly, I’d be prone to always have transients tests turned off, but I’m pretty morally opposed to transients as a general statement.

Once the two objects are passed in, it calls one the “left” object and one the “right” object. Then here are the steps it takes:

  1. If the two sides are the same object, return true.

  3. If either side is null, return false. (Personally, I’d consider null to be equal to null.)

  5. Determine the class to use to test as follows.
    1. If the left object is an instance of the right object’s class, but the right object is not an instance of the left object’s class, then use the right object’s class. This is the scenario where the right hand object is an instance of a child class of the left hand object’s class.

    3. If the right object is an instance of the left object’s class, but the left object is not an instance of the right object’s class, then use the left object’s class. This is the scenario where the left hand object is an instance of a child class of the right hand object’s class.

    5. If neither object’s class is an instance of the other, then return false. This is the case where two classes are different — although they may share a common ancestor.

    7. Else, arbitrarily use the left object’s class, since they are equal.


  6. Now, for the class to test and all of its super classes, determine all the fields of that class through reflection and test them.

This is better, but there are still some concerns.

First, there are a lot of technical difficulties inherent in reflection. Private classes are notoriously picky, and the handling of them in the various reflection-based methods are pretty inconsistant. To fix this, the Commons-Lang code sets the accessability of the fields to true, which is a start, but the maintenance on all of this is kind of ugly. There is also significant overhead to reflection, which you’re now hitting on every time you try to walk a list, insert into a tree, etc., etc. — some caching might be able to help this, as long as the number of different classes you’re encountering within a window stays reasonably small.

There’s another couple of issues which I would probably go so far as to call “bugs”.

First, variables belonging to inner classes aren’t checked. Inner classes which implement interfaces and contain data are exceedingly common — the most common examples are the Map.Entry and Iterator interfaces. I also have many times when I will have an inner class which provides the “doIt”-ness of the class, while the class itself does clean-up and maintenance on that “doIt”-ness. Similarly, anonymous inner classes that inline an object reference or value (see “closures”) could generate false positives, because the “value equality” and “functional equality” of those classes are drastically different.

Second, two classes that are sibling classes but value-equivalent cannot have their equality properly determined through this method — in fact, they’ll always be false. If two classes both implement a base abstract class, and are to be considered equal in some cases, then we’re in trouble. Think about the Number class and its various descendents — in this case, a Float with a value of 1 and an Integer with the value of 1 would be identified as not being equal. This case is so weird and identifying when it’s supposed to be equal and when it’s not is so hard that I would generally punt back to the user to have to address this case. I’m not sure how the user isn’t going to handle it, but I don’t fault the Commons-Lang developers for leaving this bug in play.

That said, it’s easier to use the reflection mode in the EqualsBuilder class than to try to actually generate a sensical work-around for the equals() problem. It’s not a perfect solution, but it’s a reasonable hack that sacrifices performance for correctness…at least, correctness in more cases.

This is your brain; this is your brain on OCaml December 16, 2005 | 10:02 am

I just had code handed to me by an employee who wrote during his 2 weeks notice. We encountered a bug in one of his classes, and since I was writing JUnit tests anyways, I figured I would do a bit of clean-up.

What I didn’t realize is that Ocaml has warped me, and my concept of “cleanup” is very different than everyone else’s.

This is the original code:

public static String[] findAvialable(int startValue, int endValue, String[] usedValues) {
    ArrayList values = new ArrayList();
    int total = endValue - startValue + 1;
    for (int i = 0; i &lt; total; i++) {
      int currentValue = startValue + i;
      boolean used = false;
      for (int j = 0; j &lt; usedValues.length; j++) {
        if (Integer.parseInt(usedValues[j]) == currentValue) {
          used = true;
      if (!used) {
        values.add(new Integer(currentValue));
    String[] result = new String[values.size()];
    for (int i = 0; i &lt; result.length; i++) {
      result[i] = ((Integer)values.get(i)).toString();
    return result;

This is what I did to it after “cleanup”:

   * Returns a string array consisting of all the integer values between two points
   * whose string representation is not in usedValues.
   * @param startValue int The minimum allowed value (inclusive).
   * @param endValue int The maximum allowed valued (inclusive).
   * @param usedValues String[] The String representation of the used integers, or null.
   * @return String[] The String representation of the available integers.
  public static String[] findAvialable(final int startValue, final int endValue,
                                       final String[] usedValues) {
    // Validate some assumptions
    if (startValue &gt; endValue) {
      throw new IllegalArgumentException("Cannot have a start value greater than the end value");
    // Cache a repeatedly calculated value
    final int length = endValue - startValue + 1;
    // Handle a simple case
    if (usedValues == null || usedValues.length == 0) {
      final List out = new ArrayList(length);
      for (int i = 0; i &lt; length; i++) {
        out.add(Integer.toString(startValue + i));
      return (String[])out.toArray(ArrayUtils.EMPTY_STRING_ARRAY);
    // Validate usedValues for the complicated case
    if (Arrays.asList(usedValues).contains(null)) {
      throw new IllegalArgumentException("Used values may be null, but may not contain null");
    // Create a set of used values as Integers.
    final Set used = SetUtils.transformedSet(new HashSet(length), new Transformer() {
      public Object transform(final Object object) {
        return new Integer(Integer.parseInt(object.toString()));
    // Add all the used values
    // Create a list of values we can use
    final List avail = ListUtils.transformedList(new ArrayList(length),
    // Add those possible start values that
    for (int i = 0; i &lt; length; i++) {
      final Integer iObj = new Integer(startValue + i);
      if (!used.contains(iObj)) {
    return (String[])avail.toArray(ArrayUtils.EMPTY_STRING_ARRAY);

The sick part is that I didn’t even realize how functional that code was until I walked through it.

A Java Gotcha October 28, 2005 | 10:31 am

Java has a universal “equals” method, as well as a “Comparable” interface that defines “natural comparison”. I always had a distaste for that design decision, and that distaste has just been further validated.

So, I have a class which looks like this:

     public class TwoDeePoint implements Comparable {
          public int x = 0;
          public int y = 0;
          public boolean equals(final Object obj)  {
                    if(obj == null || !(obj instanceof TwoDeePoint)) {
                              return false;
                    } else {
                              TwoDeePoint them = (TwoDeePoint)obj;
                              return them.x == this.x && them.y == this.y;
          public int compareTo(final Object o) {
                    if(o == null) {
                              throw new NullPointerException();
                    } else if(!(o instanceof TwoDeePoint)) {
                              throw new ClassCastException();
                    } else {
                              final TwoDeePoint them = (TwoDeePoint)o;
                              final int xCmp = new Integer(this.x).compareTo(new Integer(them.x));
                              final int yCmp = new Integer(this.y).compareTo(new Integer(them.y));
                              return xCmp != 0 ? xCmp : yCmp;

Even ignoring certain religious/performance fights (like whether the trinary operator is evil, why I declare so much crap “final” and whether the “x” member variable should be “X“, or even visible at all…), there is a major error to this code. Specifically, consider this class:

     public class ThreeDeePoint extends TwoDeePoint implements Comparable {
          public int z = 0;
          public boolean equals(final Object obj)  {
                    if(obj == null || !(obj instanceof ThreeDeePoint)) {
                              return false;
                    } else {
                              final ThreeDeePoint them = (ThreeDeePoint)obj;
                              return super.equals(obj) && them.z == this.z;
          public int compareTo(final Object o) {
                    if(o == null) {
                              throw new NullPointerException();
                    } else if(!(o instanceof ThreeDeePoint)) {
                              throw new ClassCastException();
                    } else {
                              final ThreeDeePoint them = (ThreeDeePoint)o;
                              final int supCmp = super.compareTo(them);
                              final int zCmp = new Integer(this.z).compareTo(new Integer(them.z));
                              return supCmp != 0 ? supCmp : zCmp;

See the problem yet? Guess the result of the following snippet of code:

          final TwoDeePoint a = new TwoDeePoint();
          a.x = 1;
          a.y = 2;
          final ThreeDeePoint b = new ThreeDeePoint();
          b.x = a.x;
          b.y = a.y;
          c.z = 3;

The answer is that the snippet will print out:


And there’s the problem: the equality operator, which is designed into all classes and is so critical to the operation of so many standard collections, has a very common and glaring issue. Given this implementation, a Set of TwoDeePoint and ThreeDeePoint objects may or may not insert a new ThreeDeePoint if its x and y are the same as an existant TwoDeePoint, and the deciding issue which equals method the programmer decided to call. Since the equals method is reflexive by definition, it shouldn’t make a difference…but it does.

The kludge that all Java programmers need to burn permenently into their brain can be modelled after the following change to the TwoDeePoint class:

          public boolean equals(final Object obj)  {
                    if(obj == null || !(obj instanceof TwoDeePoint)) {
                              return false;
                    } else {
                              TwoDeePoint them = (TwoDeePoint)obj;
                              if(them.x == this.x && them.y == this.y) {
                                        if(them.getClass() == this.getClass()) {
                                                  return true;
                                        } else {
                                                  return them.equals(this);

At the point when we do the class check, we know that they are an instance of our class. If they are not precisely our class, then they are an instance of a child class, and we should make sure that they are equal to us. A similar change also needs to be made to compareTo.

Of course, if I’ve got a Collection of arbitrary TwoDeePoint objects, I now know that two of them may not be equal even though their x and y values are equal, so if I only care about the x and y values, I need to write my own method to compare them which is external to the TwoDeePoint class, which really begs the question of whether that equals method is worth anything at all…

EDIT: I just realized that my code has a possible infinite recursion case. Specifically, if two ThreeDeePoint objects compare to eachother, they’ll end up spinning infinitely into the abyss. Crap…I don’t know if there is a solution to this problem without breaking its object-oriented nature (e.g.: explicitly checking x and y in ThreeDeePoint)…