A Quantum Immortal

There’s a new group in town.

If you’re a Java/JVM developer, and live in the Tel Aviv (or Israel) area, please join.

I don’t like repeating myself, so please, if you fit the above criteria, read the linked post.

A little while ago, while coding Bitcoin Pie, I found the need to overcome the notorious Same Origin Policy that limits the domains javascript running on a client’s browser can access. Via Stack Overflow I found a site called Any Origin, that’s basically the easiest way to defeat Same Origin Policy without setting up a dedicated server.

All was well, until about a week ago,  Any Origin stopped working for some (but not all) https requests. It just so happened that in that time I had gained some experience with Play! and Heroku, which enabled me to quickly build an open source clone of Any Origin called Whatever Origin (.org!) (on github). For those unfamiliar with Play! and Heroku, let me give a short introduction:

Heroku is one of the leading PaaS providers. PaaS is just a fancy way of saying “Let us manage your servers, scalability, and security … you just focus on writing the appliaction.” Heroku started as a Ruby shop, but they now support a variety of programming languages and platforms including python, java, scala, javascript/Node.Js. What’s extra cool about them is that they offer a huge set of addons ranging from simple stuff like Custom Domains and Logging through scheduling, email, SMS, and up to more powerful addons like Redis, Neo4j and Memcached.

Now for the application part, I had recently found Play! Framework. Play is a Java/Scala framework for writing web applications that borrows from the Ruby on Rails / Django ideas of providing you with a complete pre-built solution, letting you focus on writing your actual business logic, while allowing you to customize everything later if needed. I encourage you to watch the 12 minute video on Play!’s homepage, it shows how to achieve powerful capabilities from literally scratch. Play! is natively supported at Heroku, so really all you need to do to get a production app running is:

• play new
• Write some business logic (Controllers/Views/whatnot)
• git init … git commit
• “heroku apps add” to create a new app (don’t forget to add “–stack cedar” to use the latest generation Cedar stack)
• “git push heroku master” to upload a new version of your app … it’s automatically built and deployed.

Armed with these tools (which really took me only a few days to learn), I set out to build Whatever Origin. Handling JSONP requests is an IO-bound task – your server basically does an HTTP request, and when it completes, it sends the response to your client wrapped in some javascript/JSON magic. Luckily Play!’s support for Async IO is really sweet and simple. Just look at my single get method:

public static void get(final String url, final String callback) {
    F.Promise<WS.HttpResponse> remoteCall = WS.url(url).getAsync();
 
    await(remoteCall, new F.Action<WS.HttpResponse>() {
        public void invoke(WS.HttpResponse result) {
            String responseStr = getResponseStr(result, url);   // code for getResponseStr() not included in this snippet to hide some ugly irrelevant details
 
            // http://blog.altosresearch.com/supporting-the-jsonp-callback-protocol-with-jquery-and-java/
            if ( callback != null ) {
                response.contentType = "application/x-javascript";
                responseStr = callback + "(" + responseStr + ")";
            } else {
                response.contentType = "application/json";
            }
 
            renderJSON(responseStr);
        }
    });
}

The first line initiates an async fetch of the requested URL, followed by registration to the completion event, and releasing the thread. You could almost think this is Node.Js!

What actually took me the longest time to develop and debug was JSONP itself. The information I found about it, and jQuery’s client-side support was a little tricky to find, and I spent a few hours struggling with overly escaped JSON and other fun stuff. After that was done, I simply pushed it to github, registered the whateverorigin.org domain for a measly $7 a year, and replaced anyorigin.com with whateverorigin.org in Bitcoin Pie’s code, and voila – the site was back online.

I really like developing websites in 2011 – there are entire industries out there that have set out to make it easy for individuals / small startups to build amazing products.

Another less known feature in Google Guice is map binders. I haven’t seen a good basic map binder tutorial, so I wanted to share the little I learned about it (it is covered in the documentation, but it’s not necessarily the best intro material). Basically, is a way to collect bindings from several models into one central map. The idiom is having each module add bindings from its “knowledge domain”, and providing the entire collection as one unified map.

class SomeModule {
  protected void configure() {
     // Bind the value "Eve" to the key "Adam"
     MapBinder.newMapBinder(binder(), String.class, String.class)
       .addBinding("Adam").toInstance("Eve");
  }
}
 
class AnotherModule {
  protected void configure() {
     // Bind the value "Abel" to the key "Kane"
     MapBinder.newMapBinder(binder(), String.class, String.class)
       .addBinding("Kane").toInstance("Abel");
  }
}
 
class NeedsMap {
  @Inject
  NeedsMap(Map<String, String> biblicalNames) {
    // gets a map of all values bound in the relevant modules
  }
}
 
main() {
  NeedsMap needsMap = Guice.createInjector(new SomeModule(), new AnotherModule()).getInstance(NeedsMap.class);
}

Of course, the map can be specified using any types, not just String, and doesn’t have to bind to a specific instance, but can bind to a class. To use this, remember to depend on the proper Guice Extension (Maven guice-multibindings). The code is available on Github. Check out this questions for “when is this actually useful?“

Dependency Injection* is a common and useful design pattern. It moves the responsibility for creating a class’ dependencies out to its instantiater, thus allowing for easier customization and testability. A useful DI flavor is to create constructors that directly depend on a set of components, and having the caller provide these arguments upon construction. A DI framework (e.g. Guice for Java or StructureMap for .Net) will save you the trouble of having to pass along these dependencies directly, and instead turn your object construction into beautiful magic such as:

// In real code you will usually use a Provider instead of an Injector
Foo foo = injector.getInstance(Foo.class)

Instead of

Foo foo = new Foo(bar, baz, boom, .......)

This technique is easiest when a class only depends on services and other general classes.
The problem starts when a class just has to have a real, “non standard” paramater passed upon construction (e.g. a TestRunner class that accepts a numberOfRetries parameter). In simple cases, you might just forgoe the use of your DI framework for the simplicity of writing

new TestRunner(3)

But what do you do when your class has both a lot of dependencies, and a parameter you just have to pass during construction time?
One option is using a setter to pass along the actual argument, instead of requiring it during construction. While this can work, it has the shortcomings of not being able to store this value in a final field, and not being able to use it during the constructor, often forcing
you to create a separate init() method.

Another possible option is creating a separate factory class. This class will contain all the “easy” dependencies of the original class, and not the parameter. You can construct such a class with the DI framework directly, and then pass the parameter to its build() method. This skips over the disadvantages of the setter approach, and makes the calling code rather clean, but has the small problem of a code duplication between the factory and the class being built – this is especially apparent if the target class has a huge number of parameters – the factory class is essentially boilerplate “stupid” code.

Introducing … Assisted Injection (applause)

Assisted injection is a Guice concept that elegantly solves the parametric construction problem. It is actually documented quite well, so I’ll just describe it briefly – you only need to declare a factory interface, annotate the relevant constructor parameters with @Assisted, tell guice the name of the builder interface for a given class and you’re home free – Guice creates the boilerplate factory class described above behind the scenes.

Foo foo = injector.getInstance(FooBuilder.class).build(3);

* For the purpose of this post I tream Dependency Injection and Inversion of Control as the same pattern, although they are technically two related yet different patterns.

What’s the most important fault in the following java code (thanks to Roman for both writing and finding the bug )?

public class Worker extends Runnable {
...
 
    @Override
    public void run() {
        while(true){
            synchronized (emailMessages){
                try {
                    while(emailMessages.isEmpty()){
                        emailMessages.wait();
                    }
                    mappings.saveMultiple(emailMessages);
 
                }catch (InterruptedException e) {
 
                    Thread.currentThread().interrupt();
                    throw new RuntimeException(e);
 
                } finally{
                    emailMessages.clear();
                }
            }
        }
    }
}

I was of need of a Java Class Loader that can load classes from within a war file.
It took me a bit to find this – in fact, I found it when I looked for ZipClassLoader (a war file is a zip with a specific folder structure). I found this post, and modified it to take the war folder structure into account:

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.zip.ZipEntry;
import java.util.zip.ZipFile;
 
/**
 * Loads classes from war files. See http://www2.java.net/blog/2008/07/25/how-load-classes-jar-or-zip
 */
public final class WarClassLoader extends ClassLoader {
    private final ZipFile file;
 
    public WarClassLoader(String filename) throws IOException {
        this.file = new ZipFile(filename);
    }
 
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        ZipEntry entry = this.file.getEntry("WEB-INF/classes/" + name.replace('.', '/') + ".class");
        if (entry == null) {
            throw new ClassNotFoundException(name);
        }
        try {
            byte[] array = new byte[1024];
            InputStream in = this.file.getInputStream(entry);
            ByteArrayOutputStream out = new ByteArrayOutputStream(array.length);
            int length = in.read(array);
            while (length > 0) {
                out.write(array, 0, length);
                length = in.read(array);
            }
            return defineClass(name, out.toByteArray(), 0, out.size());
        }
        catch (IOException exception) {
            throw new ClassNotFoundException(name, exception);
        }
    }
}

Two notes:

1. This code isn’t really production grade, as the streams aren’t closed and whatnot
2. It is missing one critical addition – if the classes in the war depend on the jars that are included within it, this class loader will not be able to load these classes. I managed to work around the problem because I already had all those jars in my classpath anyway, but in principle the code above needs a bit of extension to be able to work with the embedded jars.

Lately I need to support task cancellation in a Java process I’m working on. The straightforward options I know to implement this are:

1. Thread.interrupt() – the caller interrupts the worker thread (either directly or using Future.cancel()). Some say this is an erroneous approach, but I still haven’t figured out why. However, it is buggy on some recent versions on the JDK, and it is a bit fragile (what if the worker threads create worker threads that also need to be canceled?).
2. Passing some object (AtomicBoolean?) down to every object you would like to support cancellation. These objects will check the value of this boolean, and should stop if it is false. They can pass the boolean to other objects / tasks. While this works, this boolean cannot be injected, and so must be manually passed along the call stack.

If you want the advantages of the second method, but don’t want to break IOC, here’s how:

First, the usage:

The listener object adds a dependency on ICancelor

public class Foo {
  public Foo(ICancelor cancelor) {
    this.cancelor = cancelor;
    ...
}

It then checks the cancellation state every now and then:

if (cancelor.wasTaskCanceled("TakeOverTheWorld"))
   return;

The top-level thread that wishes to cancel a task simply calls

cancelor.cancelTask("TakeOverTheWorld");

And whenever a task is started, you should call

cancelor.resetTask("TakeOverTheWorld");

I’ll admit using strings for task names is a bit ugly, but this is not a terrible price to pay, assuming you have a few core tasks you intend to support. All that remains is the cancellation service itself:

/**
 * A cancellation service.
 */
public interface ICancelor {
    /**
     * Resets a task to "Not canceled" state
     */
    void resetTask(String name);
 
    /**
     * Returns true iff the a cancelTask was called, and no resetTask was called afterwards.
     */
    boolean wasTaskCanceled(String name);
 
    /**
     * Cancel a task
     */
    void cancelTask(String name);
}
 
public class Cancelor implements ICancelor {
  private final ConcurrentHashMap tasks = new ConcurrentHashMap();
 
    public void resetTask(String name) {
        tasks.put(name, true);
    }
 
    public boolean wasTaskCanceled(String name) {
        Boolean value = tasks.get(name);
        return value != null & value;
    }
 
    public void cancelTask(String name) {
        tasks.put(name, false);
    }
}

Because we rely on task names, there is an assumption here that all classes that play in the cancellation game belong to the same task semantically. If a class is a common class that doesn’t belong to a single task or flow, this approach does not work – in fact, I cannot think of an approach that will work in this case with dependency injection. The common class has to accept the cancellation signal somehow, it must either get an boolean explicit and not from the IOC container, or must check its interrupted state (or some other thread-local state) itself. Any smart ideas on how to solve this problem?

I’ve posted a lot lately,  but I think this post is well deserved. Tomer has recently finished an open source project he’s been working on for quite some time – ant-intellij-tasks. It is an ant task that takes an intellij-format project structures, builds and tests it. We have been using it for the past two months or so, and I must say it has brought great joy to the CI. Before that, we used to maintain two separate sets of files – IntelliJ project files, because that’s our IDE of choice, and Eclipse files, because … that’s how the build system worked. Many a times the build broke because one did not apply a change to the eclipse file, and “it all worked on his machine“. No more (we still have broken builds, but usually not because of compilation errors).

In related news, JetBrains recently open-sourced IntelliJ itself. Tomer’s work is still worth while, simply because there is no other tool we know of that does what it does – however the code there might use some refactoring now that he can simply use portions of the IntelliJ codebase. If you want to help, go on to the project homepage.