Programming

Java signal handler implementation

2010-10-20T07:58:00.000-07:00

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);
               System.exit(1);
           }
       });
       Signal.handle(new Signal("TERM"), signalHandler);
       Signal.handle(new Signal("INT"), signalHandler);

       try {
           Thread.sleep(50000);
       }
       catch (InterruptedException e) {
           System.err.println("Interrupted");
       }
   }
}

Java Comparable and equals() implementation

2010-06-29T14:08:00.000-07:00

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;
    
    @Override
    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;
    }
}

Why Singletons Are Controversial

2009-01-12T16:20:00.001-08:00

I found a good article about why Singletons should not be used: Why Singletons Are Controversial

jBoss deployment error message

2008-06-27T09:26:00.000-07:00

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
         arguments.

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 SomeService.java) and the bean definition (usually called SomeBean.java). 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:

C++ operator< implementation

2008-01-03T10:36:00.000-08:00

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;
  }
}