Wednesday, October 20, 2010

Java signal handler implementation

Here is a Java signal handler implementation. The signal will be handled even though Thread.sleep is running.
import sun.misc.Signal;
import sun.misc.SignalHandler;

public class Test
   public static void main(String[] args)
       SignalHandler signalHandler = new SignalHandler() {
           public void handle(Signal signal) {
               System.err.println("Exiting because of signal: " + signal);
       Signal.handle(new Signal("TERM"), signalHandler);
       Signal.handle(new Signal("INT"), signalHandler);

       try {
       catch (InterruptedException e) {

Tuesday, June 29, 2010

Java Comparable and equals() implementation

It is strongly recommended (though not required) that the natural ordering of a class (compareTo() method) be consistent with the equals() method (see java.lang.Comparable). The best way to keep them consistent, is to implement the equals() method as a call to the compareTo() method. This will increase the maintainability of the code: if any new fields are added to the class in the future, they will only have to be added to the compareTo() method, the equals() method will not have to be changed. When calling compareTo() from equals(), we need to be careful, because e.compareTo(null) should throw a NullPointerException even though e.equals(null) returns false.
public class ComparableExample implements Comparable<ComparableExample>
    private int number;
    private boolean bool;
    private String str;
    private Object obj;
    public boolean equals(Object o)
        if (null == o) { return false; }
        if (this == o) { return true; }
        if ( ! (o instanceof ComparableExample) ) { return false; }

        return 0 == compareTo((ComparableExample)o);

    public int compareTo(ComparableExample that)
        final int BEFORE = -1;
        final int EQUAL  = 0;
        final int AFTER  = 1;

        if (null == that) { throw new NullPointerException(getClass().getSimpleName() + ".compareTo() called with a null parameter"); }
        if (this == that) { return EQUAL; }

        int result = EQUAL;
        if (EQUAL == result) { result = (this.number < that.number ? BEFORE : (this.number > that.number ? AFTER : EQUAL)); }
        if (EQUAL == result) { result = (this.bool ? (that.bool ? EQUAL : AFTER) : (that.bool ? BEFORE : EQUAL)); }
        if (EQUAL == result) { result = (null == this.str ? (null == that.str ? EQUAL : BEFORE) : this.str.compareTo(that.str)); }
        if (EQUAL == result) { result = (null == this.obj ? (null == that.obj ? EQUAL : BEFORE) : this.obj.compareTo(that.obj)); }
        return result;

Monday, January 12, 2009

Friday, June 27, 2008

jBoss deployment error message

When you deploy, jBoss automatically checks the structural integrity and Specification compliance of the JAR file. If this check fails, the JAR has not been deployed. The error messages are relatively helpful; for example:
Bean   : SomeEJB
Method : public abstract returnType methodName(parameters)
         throws RemoteException,...
Section: 7.10.5
Warning: The methods defined in the remote interface must
         have a matching method in the bean's class with
         the same name and same number and types of
Not only has jBoss detected a violation of the EJB Specification, it has indicated which section of the Specification to look at (7.10.5 in this case). If you see messages like this, you need to correct the code. However, jBoss doesn't say what is the exact difference between the remote interface (usually called and the bean definition (usually called Check all of the following: the method name, the type of its parameters, the list of exceptions it throws and its scope. Here is how it should be usually:

Thursday, January 3, 2008

C++ operator< implementation

class Foo
  int         a;
  float       b;
  std::string c;

  /* ... */

  bool operator<(const Foo& foo) const
     if (a != foo.a) return a < foo.a;
     if (b != foo.b) return b < foo.b;
     if (c != foo.c) return c < foo.c;
     return false;