I’ve been working on some performance testing profiling and in trying to diagnose a fix, we found one particular method was being called constantly. Searching for usages (static analysis) tells me who could possibly call the method we were inspecting, but we were interested in the runtime invocations. Since this was quite deep in the code, I used the power of dynamic proxies to do this.

I’ve rebuilt the code here:

Source:

package com.thekua.examples;

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

public class TraceBackProxy implements InvocationHandler {
    public static interface CallingMethodListener {
        void notify(String method);
    }

    private final Object wrapped;
    private final CallingMethodListener listener;

    private TraceBackProxy(Object wrapped, CallingMethodListener context) {
        this.wrapped = wrapped;
        this.listener = context;
    }

    public static Object wrap(Object target, CallingMethodListener context) {
        Class targetClass = target.getClass();
        return Proxy.newProxyInstance(targetClass.getClassLoader(),
                targetClass.getInterfaces(), new TraceBackProxy(target, context));
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] arguments) throws Throwable {
        String callingMethod = findCallingMethod(method);
        listener.notify(callingMethod);
        return method.invoke(wrapped, arguments);
    }

    private String findCallingMethod(Method method) {
        try {
            throw new RuntimeException();
        } catch(RuntimeException e) {
            StackTraceElement[] elements = e.getStackTrace();
            int callingMethodIndex = findIndexOfMethod(elements, method) + 1; // caller is next one down in stack
            return elements[callingMethodIndex].getMethodName();
        }
    }

    private int findIndexOfMethod(StackTraceElement[] elements, Method method) {
        for (int i = 0; i < elements.length; i++) {
            StackTraceElement current = elements[i];
            // does not cope with overloaded or duplicate method names
            if (current.getMethodName().equals(method.getName())) {
                return i;
            }
        }
        throw new IllegalStateException("Something went wrong and couldn't find method in stacktrace");
    }
}

Test:

package com.thekua.examples;

import org.junit.Test;

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsEqual.equalTo;
import static org.junit.Assert.assertThat;

public class TraceBackProxyTest {

    public static interface SomeRole {
        void doStuff();
    }

    public static class TestSubject implements SomeRole {
        public boolean called;

        @Override
        public void doStuff() {
            called = true;
        }
    }

    @Test
    public void shouldStillDelegate() {
        TestSubject target = new TestSubject();
        SomeRole action = (SomeRole)TraceBackProxy.wrap(target, new TestOnlyListener());

        action.doStuff();

        assertThat(target.called, is(true));
    }

    public static class TestOnlyListener implements TraceBackProxy.CallingMethodListener {
        String lastCalledMethod;

        @Override
        public void notify(String method) {
            lastCalledMethod = method;
        }
    }

    @Test
    public void shouldFindCallingMethod() {
        TestOnlyListener listener = new TestOnlyListener();
        SomeRole action = (SomeRole) TraceBackProxy.wrap(new TestSubject(), listener);

        action.doStuff();

        assertThat(listener.lastCalledMethod, equalTo("shouldFindCallingMethod"));
    }
}

Note that your mileage may vary since it probably won’t work when you have duplicate method names across classes, or overloaded methods on the same. It proved useful for me and hope it helps you.

Just like a certain number of speakers, Maven seems to divide developers into two camps:

1. Those who like it; and
2. Those who loathe it

I try to be objective as much as possible about tools, so let’s explore what Maven is and what it’s good for.

What’s Maven all about?
Maven has two major responsibilities (with a handful of minor ones). These two are:

1. Library dependency management – Anyone who’s worked on a java project will know the large number of libraries you might end up with. Part of this is the JDKs inability to solve some of the simplest programming problems (solved with Apache Commons, various logging frameworks, etc). Maven was one of the first successful attempts at fixing this, focusing on applications on what version of libraries they’d like with its dependencies automatically resolved.
2. Build lifecycle tool – Maven provides a standard set of fixed build lifecyles with hooks for each step in the lifecycle should you need to extend it.

Why was Maven developed?
To better understand Maven’s design, let’s look at the context developers built it in. Maven sprung forth out of the growing complexities in the Java Apache community. New Apache projects started off almost all the time and there was no “standard” way of building, or creating them. More than that, many Apache projects built on the work of other projects and managing the versioning of libraries started to become an onerous task.

Each Apache project characteristically depended on several other projects although generated its own single distributable (i.e. jar, war, etc).

Maven helped simplify these by assuming a default project structure, a default build lifecycle common to all many Apache projects.

Where is Maven most useful?
If you’re on a project that is similar to a single Apache project (a single distributable with a single set of unit tests) then you’ve hit Maven’s sweet spot.

Where does Maven start to break?
Here are some of the situations I’ve faced where Maven is not the best tool for the job:

• When one team is producing a number of artefacts, you find yourself needing to work around the Maven structure, often with resorting to “Pom Inheritence”. You have to do ugly things like maven installs before hand.
• If you need to do anything more complex than the standard build, then you start to obfuscate the build process. Strange things like different processes running under different profiles (whether or not the build is running on a build server or not) can be very confusing for lots of people.
• Maven adds more complexity to your development environment as you rely on either a public artefact server, or need to set up an internal one. Whilst this seems simple, it is yet another environmental factor that affects how you develop, and its external nature adds variability to projects that often cause false negative build failures.

What other situations would your recommend using Maven or not?