Atomic transaction in J2EE

As budding developers, most of us tend to debate on certain technologies out there and comment on which is better than which and why. dotNet developers will argue that J2EE is so hard to use while the latter will comment that dotNet does not scale and is not as reliable. Even within the J2EE environment, some developers does not see EJB as a useful feature of J2EE and comment that it is difficult to develop and the same results can be achieved merely by using JDBC. There are even others who said that using stored procedures will result in most efficient code. Efficient here means fastest to execute and return desired results. As I am also one of the budding developers, I also face this type of debates most of the time. I still does not know which one is most efficient and which one should I use in which type of situation. However, I does realize the fact that session beans and entity beans removed a lot of the headache of maintaining transactions in JDBC environment. Container managed transaction is a blessing for Java developers. Anyway, the point is, I actually like to find out WHAT IF the transaction that is guaranteed by the container fails. I mean, say the task A and task B must occur as one atomic transaction but actually only task A managed to run but the transaction is unable to roll it back or worst, does not even realized it. Who would be responsible for this behavior? Most of the time it would be developers fault for not understanding the J2EE spec correctly and made mistakes while developing, however one cannot simply rule out that the application server vendor is not at fault. What if this funny behavior is randomly appearing at production systems and the developers are sure that their application are coded correctly. Who are liable for financial lost that occurred because of application servers funny inconsistent behavior?

Death March

What is a Death March Project and why does it happens? I think every project manager should go and buy this book and read it before planning for the next project as to avoid the following : The immediate consequence of these constraints, in most organizations, is to ask the project team to work twice as hard and/or twice as many hours per week as would be expected in a "normal" project. Thus, if the normal work-week is 40 hours, then a death march project team is often found working 14-hour days, six days a week. Naturally, the tension and pressure escalate in such environments, so that the death march team operates as if it is on a steady diet of Jolt cola. I think most of us developers had already experienced this before and would not like to experience it again. This book will justify that developers are usually innocent in Death March and need not go thru all those suffering and tortures. If you are one of those unfortunate souls, try these Practical Suggestions for Breaking the Bad News.

The Dilbert Blog: The Devil

Interesting thoughts about stoning the devil...

Read more at dilbertblog.typepad.com...

Overloading in Tiger

I was confused with how overloading in J2SE 5.0 works, so I compiled a little example to show. Initially, I thought the code will refuse to compile but I was proven wrong. It does compile and there is some precedence to which method that will be invoked.

public class Overload {
    public static void main(String[] args) {
        Overload m = new Overload();
        short s = 0;
        m.foo(s);
    }
    
    //Direct primitive type match will take precedence
    private void foo(short l){
        System.out.println("short"); 
    }

    //Primitive type promotion will take precedence over Autoboxing
    private void foo(long l){
        System.out.println("long");
    }
    
    //Autoboxing will only happen when primitive or promotion not available
    private void foo(Short l){
        System.out.println("Short");
    }
}