Wave Fronts

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]

Black Thursday for Engineering?

Hoping I'm wrong

  (found on the 'Net while searching for the
    real psalm. Adapted slightly.)

  ***********
  Psalm 6.111
  ***********

  The FlipFlop is my Synchronizer, I shall
   not want.
  He maketh me pipeline my whole circuit,
  He leads me to program more EPROMs,
  He restores my sanity.

  He guides me in paths of synchronicity
   for his clock's sake.
  And lo, though I walk through the valley
   of the shadow of CMOS,
  I will fear no intermediate voltages,
   for He is gated,
  His one or His zero,
   they comfort me.

  He prepares a haven for me
   in the presence of metastability,
  He annoints my design with blocks,
   my logic shall rationalize.
  Surely good reviews and no recalls will
   follow me all the days of this fiscal
   year, and I will create the right buzz
   forever.

----

Wishing all of you safe passage,
dear friends at Sun.

Posted at 12:00AM Jun 22, 2006 by microwaves in General  |  Comments[0]