Wave Fronts

java.lang.ThreadLocal UniqueThreadIdGenerator example FIX

A typo crept into the new ThreadLocal example class somehow. Here's the code as it SHOULD be:

 import java.util.concurrent.atomic.AtomicInteger;

 public class UniqueThreadIdGenerator {

     private static final AtomicInteger uniqueId = new AtomicInteger(0);

     private static final ThreadLocal < Integer > uniqueNum = 
         new ThreadLocal < Integer > () {
             @Override protected Integer initialValue() {
                 return uniqueId.getAndIncrement();
         }
     };
 
     public static int getCurrentThreadId() {
         return uniqueNum.get(); // CORRECT
     }
 } // UniqueThreadIdGenerator

The INCORRECT example code that escaped into Java SE 6 invokes uniqueId.get instead.

This problem was apparently caused by the fact that the unit test I used to test the putback "wasn't good enough" and the fancy replacement's debugging collided with time constraints for the release. I guess I put the typo in at the perfect time to shift mistrust to the new unit test. There's an open bug for the latter and there will soon be an open bug for this last minute botch. There should be no problem getting this example fixed for U1.

Posted at 02:47PM Sep 27, 2006 by microwaves in Java  |  Comments[1]

Java Portability

Solaris(IBM AIX/Linux)-specific interruptible I/O is a case in point about Java portability headaches.

One source of great tension with Java programming is between the desire to use it as a general tool and the desire for it to be a truly portable platform. This is demonstrated sharply with high performance and specialized settings in which "interruptible I/O" is deemed useful, while practical issues prevent this feature being provided for Java Standard Edition (Java SE) in all operating environments. For instance this program below does nothing visible on Solaris, but prints "hello" with Sun Java SE on Linux and Windows:

public class Foo {
    public static void main(String[] args) {
        Thread.currentThread().interrupt();
        System.out.println("hello");
    }
}

First impressions of this program's behavior on Solaris roughly translate to "The hell you say!" followed by "Java is broken on Solaris!" There are a number of "symptoms" of interruptible I/O that catch users off guard and in a few cases one is led to wonder if it might be best to do without this feature whose flip side is that it allows "breaking out" of I/O operations that folks really want to be able to escape from. One could argue that the semantics are just funky and I admit to not knowing where they are written down. In fact I'd love to hear of any other versions of Java SE that support interruptible I/O. IBM Linux Java SE prior to their version 5 does support interruptibility similar to that of Sun Java SE, but it isn't clear if this "feature" extends across many other implementations. In any case, I think this is an appropriate test case for a discussion of portability.

I like to present things backwards sometimes, so let me start with the last thing on my mind, which is to wonder what could be done to "fix" interruptible I/O? That is, what could be done to make this feature less surprising or problematic?

An obvious solution would be to yank this feature where it is OE or vendor-specific and this proposal is a Sun change request. More on this later. But the key issues for this solution are the questions of who is dependent on this nonportable interruptible I/O and what they have as an alternative. The answers seem to be "almost nobody" and "java.nio" respecitively.

But more basic than this, of course, is Sun's pledge to maintain backward compatibilty "no matter what." But are some problems painful enough that they should be exceptions to this rule? The fact that Java SE on Solaris (and pre-5.0 SE on IBM AIX, Linux, etc) have such different behavior poses a terrible problem for unsuspecting developers. But even if this "acute pain" is beyond reasonable, can we leave users in the lurch? I think not, or at least not in any kind of short timeframe.

More on this later.
2

Posted at 10:42PM Jun 22, 2006 by microwaves in Java  |  Comments[0]