It made my day when I proposed to use Beanlib to solve a problem which the Jakarta Commons BeanUtils was not well suited, Beanlib ended up being included in the BeanUtils wiki as a related project :)

Thanks to Niall Pemberton for being open minded.

One common problem Java programmer faces is the direct or indirect use of socket that could block forever. If a socket connect or read operation blocks with an infinite timeout, there is basically nothing that can interrupt the blocking thread besides closing the socket. Not Thread.interrupt(), nor even Thread.stop() would help. Gaining access to the underlying socket could, however, be difficult, considering the socket could be buried deep down inside some third party library, such as a JDBC driver.

Attending the NFJS session, Busy Java Developer's Guide to JDK Hacking by Ted Neward yesterday, a solution came to my mind when Ted demonstrated how easy it was to slip in my own classes ahead of the JDK's. Why not simply extend the existing JDK socket implementation with an additional system property to limit or default the socket timeout to some sensible values ? See an example implementation below. To make this work, simply

1. Set up a custom socket factory:

   Socket.setSocketImplFactory(new SocketImplFactory() {
       @Override
       public SocketImpl createSocketImpl() { return new NicerSocksSocketImpl(); }
   });

2. Slip in the implementation class and configure the socket timeout when starting up the JVM:

   java -Xbootclasspath/p:"/path/to/custom/jdk/classes" -DSO_TIMEOUT=1000 ...

Now if a socket timeout is not specified by the individual application or library, the blocking operation would be limited to a maximum of 1,000ms before throwing up.

No more socket black hole sucking up resources:)

package java.net;
import java.io.IOException;

public class NicerSocksSocketImpl extends SocksSocketImpl {
    private final int defaultSoTimeout; 

    public NicerSocksSocketImpl() { this.defaultSoTimeout = defaultSoTimeout(); }

    public NicerSocksSocketImpl(String server, int port) {
        super(server, port);
        this.defaultSoTimeout = defaultSoTimeout();
    }

    public NicerSocksSocketImpl(Proxy proxy) {
        super(proxy);
        this.defaultSoTimeout = defaultSoTimeout();
    }
    
    private int defaultSoTimeout() {
        String defaultSoTimeoutStr = System.getProperty("SO_TIMEOUT");
        try {
            return Integer.parseInt(defaultSoTimeoutStr);
        } catch(RuntimeException ex) {
            return 5000;    // default to 5 seconds
        }
    }
    
    @Override
    protected void connect(SocketAddress endpoint, int timeout) throws IOException {
        super.connect(endpoint, timeout == 0 ? defaultSoTimeout : timeout);
    }

    @Override
    protected void connect(String host, int port) throws UnknownHostException, IOException {
        setTimeoutIfNecessary();
        super.connect(host, port);
    }
    
    @Override
    protected void connect(InetAddress address, int port) throws IOException {
        setTimeoutIfNecessary();
        super.connect(address, port);
    }
    
    private void setTimeoutIfNecessary() throws SocketException {
        int timeout = super.getTimeout();
        
        if (timeout == 0)
            super.setOption(SO_TIMEOUT, defaultSoTimeout);
        return;
    }
}

During one of today's NFJS sessions, Transaction Design Patterns by Mark Richards, the audience were asked when it would make sense to specify the transaction attribute NEVER in a real-life application.

My immediate answer to this was that if a method is known to never get involved in a transactional context, then specifying NEVER would allow the application to fail fast. But what would be the practical circumstances where a method should never get involved in a transaction, to the extent of potentially causing an exception in production ? And if there weren't really such circumstances, why not use the SUPPORTS attribute instead ? Asked Richard.

On second thought, maybe we can use the NEVER attribute a lot more often and useful than it now is. Let me explain.

Consider the transaction attribute REQUIRES_NEW, which basically creates a new transaction if one doesn't already exist. But what if there already exists a transaction ? Instead of throwing an exception, like NEVER, it would suspend the current transaction and creates a new one. However, suspending a transaction is both expensive and usually not the intended semantics, as Richard pointed out.

So wouldn't it be nice if there exists a transaction attribute

NEVER_REQUIRES_NEW

that would both guarantee there is no pre-existing transaction when a method is invoked, and then proceed to always create a new transaction ? But there is no such transaction attribute either in JEE 5, nor in Spring.

Here is what I think could achieve the NEVER_REQUIRES_NEW transaction semantics, assuming the service method name is M:

1. Split method M into M1 and M2, and move the implementation of M to M2;
   
2. M1 is a no-op annotated with the transaction attribute NEVER, whereas M2 is annotated with REQUIRES_NEW;
   
3. Provide a proxy service that always invokes M1 followed by M2, exposing in turn to the client only a service method M without any transactional annotation;
   

Now when client invokes M, the proxy would in turn invoke M1 that guarantees there is no pre-existing transaction, and then invoke M2 which would always create a new transaction, effectively resulting in NEVER_REQUIRES_NEW!

Is this yet another Transaction Design Pattern ? The use of NEVER could be forever changed :)

Given a set of objects, sometimes it's useful to find out all the permutation of these objects, and perform some action upon each permutation. The order of the permutation generation would preferably be in some natural order such as lexicographic i.e. the order they would appear if they were sorted numerically.

How would you go about writing such utility efficiently in Java ?

One possible answer:

public class Permutation<T> {
    public static interface Visitor<T> {
        /** Visits each permutation of objects. */
        public void visit(T[] entry);
    }
    private final T[] objects;
    private T tmp;
    private final Visitor<T> visitor;
    
    /**
     * @param objects set of n objects
     * @param visitor used to visit each permutation
     */
    public Permutation(T[] objects, Visitor<T> visitor) {
        this.objects = objects.clone();
        this.visitor = visitor;
    }
    
    public void compute() { doCompute(0); }
    
    private void doCompute(final int pos) {
        if (pos == objects.length) {
            visitor.visit(objects);
            return;
        }

        doCompute(pos+1);
        
        for (int i=pos+1; i < objects.length; i++) {
            swap(pos, i);
            doCompute(pos+1);
        }
        
        if (pos > 0)
            for (int i=pos+1; i < objects.length; i++)
                swap(i-1, i);
    }
    
    private void swap(int p1, int p2) {
        tmp = objects[p1];
        objects[p1] = objects[p2];
        objects[p2] = tmp;
    }
}

Demo:

Visitor<Character> visitor = new Visitor<Character>() {
    private Set<String> set = new HashSet<String>();

    @Override
    public void visit(Character[] entry) {
        String s = Arrays.toString(entry);
        set.add(s);
        System.out.println(set.size() + ": " + s);
    }
};
String s = "abc";
Character[] ca = new Character[s.length()];

for (int i = s.length() - 1; i > -1; i--)
    ca[i] = s.charAt(i);
new Permutation<Character>(ca, visitor).compute();

Would yield:

1: [a, b, c]
2: [a, c, b]
3: [b, a, c]
4: [b, c, a]
5: [c, a, b]
6: [c, b, a]

Given a set of objects, sometimes it's useful to find out all the combination of these objects of a given size, and perform some action upon each combination. For example, given a set of letters "abcde", print out all the combination of 4 letters from the set.

How would you go about writing such utility efficiently in Java ?

One possible answer:

public class Combination<T> {
    public static interface Visitor<T> {
        /** Visits each k-combination of objects. */
        public void visit(T[] entry);
    }
    private final T[] objects; // Given set of objects
    private final T[] entry;   // each combination of size k
    private final Visitor<T> visitor;

    /**
     * @param objects set of n objects
     * @param k size of each combination
     * @param visitor used to visit each combination
     */
    public Combination(T[] objects, int k, Visitor<T> visitor) {
        this.objects = objects.clone();
        entry = Arrays.copyOf(this.objects, k);
        this.visitor = visitor;
    }

    public void compute() { doCompute(0, 0); }

    private void doCompute(int pos, int entryPos) {
        if (entryPos == entry.length) {
            visitor.visit(entry);
            return;
        }
        // (entry.length - entryPos) is the remaining size
        for (int i = pos, end = objects.length - (entry.length - entryPos) + 1; i < end; i++) {
            entry[entryPos] = objects[i];
            doCompute(i + 1, entryPos + 1);
        }
    }
}

Demo:

Visitor<Character> visitor = new Visitor<Character>() {
    private Set<String> set = new HashSet<String>();

    @Override
    public void visit(Character[] entry) {
        String s = Arrays.toString(entry);
        set.add(s);
        System.out.println(set.size() + ": " + s);
    }
};
String s = "abcde";
Character[] ca = new Character[s.length()];

for (int i = s.length() - 1; i > -1; i--)
    ca[i] = s.charAt(i);

final int size = 4;
new Combination<Character>(ca, size, visitor).compute();

Would yield:

1: [a, b, c, d]
2: [a, b, c, e]
3: [a, b, d, e]
4: [a, c, d, e]
5: [b, c, d, e]