A Quantum Immortal

Hi all,

whateverorigin.org is an open source projects I started several years ago as a weekend project (github). Apparently, people are using it in production, while I have zero time to maintain it.

I am looking for an equal partner to join and help maintain the project.
This partner would fix a few ongoing issues, and can develop new features if they want. This partner would receive 50% of the ownership of the project.

The project is currently completely non-profit, it costs zero to run and makes zero revenue. However if it would make any revenue in the future, that would be split 50-50 with the new developer.

Profit aside, this could be a great opportunity for someone to get some production experience and engage with users. Be in touch at ron@reversefunder.com if you’re interested.

After a few months of gathering forces, we have a critical mass of people interesting in learning and teaching about Java & JVM related technologies.

Our first Tools Night is this upcoming Sunday (29/04), in Sears Israeli (Hertzelia Pituah).

Please check out the schdeule on EventBrite, and subscribe if you’re interested. Also don’t forget to subscribe to the google group.

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.