Friday, April 06, 2012

Golang Does Delegates Beautifully!


When working with object-oriented languages, there are many instances when one would want to implement an interface re-using code from another implementation of the interface. While inheritance will work, it couples the new implementation to the specific other implementation. Composition with delegation will be a better way of doing this.

Let's consider an application which deals with doors of different shapes. You'd have a Door type and a Shape interface implemented by different concrete shapes. You'd also have a DrawingSurface which takes any implementation of Shape and invokes draw() and fill() on it passing a graphics context.

Here's the verbose and repetitive code you'd have in Java with neither delegates nor any form of duck-typing.


In a dynamic language with meta-programming like Ruby, this is less verbose but the delegates still need to be explicitly defined. The forwardable library defines the specified methods on Door to invoke corresponding methods on @shape at run-time. However, tools like IDEs can't recognize Door as an implementation of Shape unless they handle the specific library call as a special case.


Go gives you delegates with no extra work. You just say Door has a Shape and you get statically checked and compiled delegation.


This has all the compile-time safety checks of Java with the expressiveness of Ruby. This is one of the many cases where Go's simple design makes code less verbose!

Wednesday, June 29, 2011

Hadoop's POM Conflicts with Distribution

My current project uses Hadoop to do some data munching. I hit a snag when trying to upload a file to S3 from a hadoop job using the jets3t api. We use maven to handle all the dependencies of our project including hadoop. When I deployed the job to our test cluster, I received a "java.lang.VerifyError". I couldn't find the solution on the internet so decided to blog it myself.

Turns out that the POM of hadoop-core 0.20.2 has a dependency on jets3t-0.7.1, but the hadoop distribution ships with jets3t-0.6.1 (which is incompatible with 0.7.1). Since our JAR was compiled with 0.7.1, byte code verification failed.

To fix this I had to exclude jetst3t from hadop-core dependency list,


And add an explicit dependency on jets3t 0.6.1 in our project.


That fixes it. Hope this post helps someone affected by this bug in hadoop's POM.

Friday, January 22, 2010

How Git shines above Subversion at Merging

I've recently started getting my head around Git having been a Subversion (sadly even CVS) user all along. While I liked the fact that it was distributed and way faster than Subversion at most operations, I couldn't understand why many claimed it was better at merging than Subversion (1.5 and above). Even the "Branch Handling" section in Git's wiki talks only about better history tracking but not about how Git is better at merging the content themselves.

While correct history tracking is important, merging without breaking the code is an absolute must. So I wanted to see if there was a place where Subversion would silently break the code during a merge but Git would not. This might not be new to long time Git users but I hope this would help many Subversion users take another look at Git. Without further ado, lets see how Git manages merges better.

The Workflow

You initially start off with a file named Test.java in both SVN and Git repositories with initial content as below.


You then create a branch named "refactor" and within this branch rename the class to NicerName (and consequently rename the file too) and commit to the branch.


You switch back to the main branch (trunk/master) and fix a bug. In this case we change the message being printed to "Correct Message" and commit to the main branch.


Finally, we merge the changes from the refactor branch into the main branch.

The commands

SVN would do it with the following commands.


Git would do the same with these commands.


The Result

Neither SVN nor Git complain about conflicts which is fine. However, after the merge, SVN leaves two files in the main branch. NicerName.java has the new name but doesn't have the fix while Test.java has the fix but not the new name. Here is how it looks in SVN.



Essentially your code is broken silently by SVN during the merge. On the other hand Git handles this very cleanly. It leaves only NicerName.java back including the fix to the message and removes Test.java, exactly as you'd expect.


Over all the branching and merging commands looked cleaner with Git too. This kind of excellent support for branching, refactoring and merging back alone should make everyone give Git a serious consideration. Even if Git is used in a centralized workflow just like Subversion, it can still provide huge benefits over Subversion. If you utilize its distribution features too, it just gets better!

Sunday, December 13, 2009

Simple Layouts with JSP in Spring MVC

Every web application has elements common to all its pages which are good candidates for re-use. While Spring MVC provides integration with Tiles, it can be an overkill for simple applications and needs using Spring's client side JS library for AJAX (correct me if I'm wrong).

For most applications, standard JSPs can serve as good layout engine. This post shows how Spring's handler interceptor can be used to specify a normal JSP file as the layout for a Spring MVC web application.

This interceptor allows you to specify a JSP file containing the layout for the application into which the actual views get plugged. The interceptor takes the actual model and view and replaces the actual view with the layout view's name and puts the actual view name into the model map to be used by the layout file. If you do not want to include the layout for certain requests (AJAX requests) you can prefix the view name with "noLayout:".

The Interceptor
public class LayoutInterceptor extends HandlerInterceptorAdapter {
private static final String NO_LAYOUT = "noLayout:";

private String layoutView;

@Override
public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
super.postHandle(request, response, handler, modelAndView);

String originalView = modelAndView.getViewName();

if (originalView != null && !originalView.startsWith("redirect:")) {
includeLayout(modelAndView, originalView);
}
}

private void includeLayout(ModelAndView modelAndView, String originalView) {
boolean noLayout = originalView.startsWith(NO_LAYOUT);

String realViewName = (noLayout) ? originalView.substring(NO_LAYOUT.length()) : originalView;

if (noLayout) {
modelAndView.setViewName(realViewName);
} else {
modelAndView.addObject("view", realViewName);
modelAndView.setViewName(layoutView);
}
}

public void setLayoutView(String layoutView) {
this.layoutView = layoutView;
}
}

Sample Usage
<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
<property name="interceptors">
<list>
<bean id="layoutInterceptor" class="LayoutInterceptor">
<property name="layoutView" value="layout"></property>
</bean>
</list>
</property>
</bean>

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView"></property>
<property name="prefix" value="/WEB-INF/jsp/"></property>
<property name="suffix" value=".jsp"></property>
</bean>
With that all the views returned by controllers can be included within the layout JSP by including the following line in WEB-INF/jsp/layout.jsp.
<jsp:include page="/WEB-INF/jsp/${view}.jsp"></jsp:include>

Sunday, November 01, 2009

Mocking Math.random() using PowerMock

Let's consider the below Game class in a guessing game where a random target is chosen by the system and the user guesses the target. The system returns an appropriate message based on whether the guess was higher, lower or equal to the random target.

package org.game;

public class Game {
private int target = (int) (Math.random() * 100);

public int guess(int guess) {
return target - guess;
}
}

No magic there. Now let's look at the unit test for this class.

package org.game;

// imports hidden;

public class GameTest {
private Game game;

@Before
public void setUp() {
game = new Game();
}

@Test
public void testHigherGuess() {
int result = game.guess(55);
Assert.assertTrue(result < 0);
}

@Test
public void testLowerGuess() {
int result = game.guess(35);
Assert.assertTrue(result > 0);
}

@Test
public void testCorrectGuess() {
int result = game.guess(50);
Assert.assertTrue(result == 0);
}
}

As you might have guessed by now this wouldn't work as the target is randomly generated. Now we have three options to handle this.
  1. Add a constructor taking the target value as argument and set the target using that. This would make passing a non-random value for testing simple. However, this would change the interface of the class unnecessarily.
  2. Access "target" using reflection and set its value after object creation. However, this would make the unit test fragile as it knows too much about the internals of the class under test.
  3. We can make Math.random() to return a constant value within our test case. This is the approach demonstrated in this post.
PowerMock is a mocking framework which extends several popular frameworks to allow mocking of static methods and more. In this post we'll use PowerMocks' extension for EasyMock. The general technique to mock static methods using PowerMock is outlined here.

This wouldn't work for system classes like Math. To workaround this, we can prepare the class using the static method for test rather than the class containing the static method. Which means we'd be using @PrepareForTest(Game.class) instead of @PrepareForTest(Math.class) in our case. The completed unit test would look like this.

package org.game;

// imports hidden

@RunWith(PowerMockRunner.class)
@PrepareForTest(Game.class) // Preparing class under test.
public class GameTest {
private Game game;

@Before
public void setUp() {
// Mocking Math.random()
PowerMock.mockStatic(Math.class);
EasyMock.expect(Math.random()).andReturn(0.50).anyTimes();
PowerMock.replay(Math.class);

game = new Game();
}

@Test
public void testHigherGuess() {
int result = game.guess(55);
Assert.assertTrue(result < 0);
}

@Test
public void testLowerGuess() {
int result = game.guess(35);
Assert.assertTrue(result > 0);
}

@Test
public void testCorrectGuess() {
int result = game.guess(50);
Assert.assertTrue(result == 0);
}
}

Now PowerMock ensures that any call to Math.random() would always return a constant value within the Game class when used for testing. Hence we can test the guess() method just as how any client code using the Game class would.

Saturday, August 29, 2009

Using Javascript as DI Container in Java

Javascript is almost as dynamic as any programming language can get. However, it is mostly used only within the browser and many developers (including dynamic language fans) don't know of many of the cool language features of Javascript. When these features are used effectively, it lets us write highly expressive code which even many dynamic languages can't match.

Most Java developers turn to Spring for their DI and AOP requirements. However the configuration of Spring is quite verbose and is mostly XML. Plain JDK can handle AOP using dynamic proxies and as this post demonstrates Javascript can be used to handle the dependency injections.

Starting with Java 6, Java applications can invoke scripting languages within their JVM instance and communicate with them seamlessly using the Scripting API. Sun's JRE also ships with a built-in engine for handling Javasript through this API. We can utilize Javascript's power and expressiveness to perform cool stuffs on top of the JVM.

What are we Building?
  1. Two DAOs and their mock implementations.
  2. A sample service utilizing these DAOs.
  3. JS script wiring them up together.
  4. A simple interceptor to log invocations of service methods.
DAOs
package dao;

public interface BooksDAO {
public int count();
}

package dao;

public interface MembersDAO {
public int count();
}

package dao;

public class MockBooksDAO implements BooksDAO {

@Override
public int count() {
return 500;
}
}

package dao;

public class MockMembersDAO implements MembersDAO {

@Override
public int count() {
return 100;
}
}

Service
package service;

public interface LibraryService {

public abstract int countBooks();

public abstract int countMembers();

}

package service;

import dao.BooksDAO;
import dao.MembersDAO;

public class MockLibraryService implements LibraryService {
private BooksDAO booksDAO;
private MembersDAO membersDAO;

public MockLibraryService(BooksDAO booksDAO, MembersDAO membersDAO) {
this.booksDAO = booksDAO;
this.membersDAO = membersDAO;
}

public int countBooks() {
System.out.println("In countBooks()");
return booksDAO.count();
}

public int countMembers() {
System.out.println("In countMembers()");
return membersDAO.count();
}
}

DI Script

We utilize Javascript's Object literals to define and group our DAOs and services. These can then looked up from our applications to obtain the actual implementations.

src/objects.js
importPackage(Packages.dao)
importPackage(Packages.service)
importPackage(Packages.interceptor)

daos = {
booksDAO : new MockBooksDAO(),
membersDAO : new MockMembersDAO()
}

services = {
libraryService : LoggingInterceptor.getProxy(new MockLibraryService(daos.booksDAO, daos.membersDAO))
}

Application Code

We use the ScriptEngineBuilder introduced in a previous post to evaluate our Javacript and then obtain the service instance from it.

package app;

import javax.script.ScriptEngine;
import javax.script.ScriptException;

import service.LibraryService;
import util.ScriptEngineBuilder;

public class Main {
public static void main(String[] args) throws ScriptException {
ScriptEngine engine = new ScriptEngineBuilder("js").add("/objects.js").build();

LibraryService service = (LibraryService) engine.eval("services.libraryService");

System.out.println("Found " + service.countMembers() + " Members!");
System.out.println("Found " + service.countBooks() + " Members!");
}
}

Adding AOP to the Mix

Let's create a JDK dynamic proxy to log all method invocations.
package interceptor;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class LoggingInterceptor implements InvocationHandler {
private Object target;

public static Object getProxy(Object target) {
ClassLoader loader = LoggingInterceptor.class.getClassLoader();
Class[] interfaces = target.getClass().getInterfaces();
InvocationHandler handler = new LoggingInterceptor(target);

return Proxy.newProxyInstance(loader, interfaces, handler);
}

private LoggingInterceptor(Object target) {
this.target = target;
}

@Override
public Object invoke(Object proxy, Method method, Object[] args)
throws Throwable {
try {
System.out.println("Entered Method: " + method.getName());
Object val = method.invoke(target, args);
System.out.println("Completed Method: " + method.getName());
return val;
} catch (Exception e) {
System.out.println("Exception in Method: " + method.getName());
throw e;
}
}

}

Let's now modify our service creation in DI script as below to utilize the proxy.

libraryService : LoggingInterceptor.getProxy(new MockLibraryService(daos.booksDAO, daos.membersDAO))

So there we have a nice and clean DI configuration including AOP without needing anything outside of Java SE. An important thing to note here is that we are still maintaining the DI and AOP config entirely outside our application code unlike when using annotations. Spring would have needed a truck load of XML to achieve the same!

Friday, August 28, 2009

ScriptEngineBuilder for Java

Java 6 allows you to execute and communicate with scripts written in any scripting language, using the Scripting API. However, the code needed to create a ScriptEngine and evaluate a set of script files within it, is quite verbose and throws several checked exceptions.

I decided to create a simple fluent Builder which can be used to create a ScriptEngine and execute a set of script files inside it. It also allows you to add Java Objects into the engine before executing the script files.

ScriptEngineBuilder
import java.io.InputStreamReader;
import java.net.URL;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;

public class ScriptEngineBuilder {
private ScriptEngine engine;

public ScriptEngineBuilder(String shortName) {
this.engine = new ScriptEngineManager().getEngineByName(shortName);
}

public ScriptEngineBuilder add(String scriptResource) {
try {
URL scriptURL = getClass().getResource(scriptResource);
InputStreamReader scriptReader = new InputStreamReader(scriptURL.openStream());
engine.eval(scriptReader);

return this;
} catch (Exception e) {
throw new RuntimeException(e);
}
}

public ScriptEngineBuilder put(String key, Object value) {
engine.put(key, value);
return this;
}

public ScriptEngine build() {
return engine;
}
}


Applications can create an instance of ScriptEngineBuilder by passing the shortName of the engine to the constructor. Then they can invoke add() method for the script files to be evaluated (as classpath resource name). They can finally invoke build() to get the ScriptEngine instance.

Sample Invocation
ScriptEngine engine = new ScriptEngineBuilder("js").add("/script1.js").put("myObj", obj).add("/script2.js").build();