There is a definite need for pointing out that the circumstances in which an I/O operation can be interrupted vary. Applications cannot expect or depend on interruptibility that is Solaris-specific without giving up portability. Because the same level of support can't be offered everywhere, depending on this interruptibility (or its absence) should be carefully avoided.
But what is meant by "interruptible I/O" and what aspect of it is Solaris-specific? The general term refers to the JDK's response of throwing InterruptedIOException when thread interruption is detected during the invocation of methods that can throw IOException. Solaris-specific "VM interruption" simply refers to the Solaris-specific source of interruption, while other, platform-independent code in the JDK also provides interruption for all OS types.
Starting with jdk1.3(Kestrel), VM interruption of I/O was provided on Solaris only and this is still true for current Java SE. By "VM interruption" we mean that there is OS-specific behavior such that before the VM on Solaris initiates OS operations related to Java I/O, or after the operation has started but is found to have been interrupted by a signal (i.e. with errno==EINTR), then if thread interruption is detected (effectively, as if Thread.isInterrupted() would return true) the result will be a special VM error status that typically manifests as a thrown exception. In addition, on Solaris only, the JVM translates a Thread.interrupt() method invocation into an OS-level thr_kill call that sends a signal to a thread that might be pended for I/O. This is a major source, but not the only source, of the interruption with EINTR scenario described earlier. But in combination, the Solaris-specific source of thread signals and special handling of low level I/O operations translates into a marked difference in behavior for Java SE on Solaris vs on Linux and Windows.
The interruptibility mechanism that was present in pre-1.3 versions of the JDK for Solaris could not be extended to Linux and Windows for various reasons including the maturity of threading support on Linux and resource usage complications on Windows. So, as he Description states, there has been a major contrast of Java SE depending on it's host OS type for some time.
However, since jdk1.4(Merlin), the java.nio.channels package has provided portable mechanisms for interruptibility. See the InterruptibleChannel interface for details.
Changing Solaris-specific behavior with respect to I/O interruption could not enable withdrawal of the InterruptedIOException class, as this exception is thrown in other contexts regardless of OS type.
New Hotspot switch UseVMInterruptibleIO has been added to Java SE 6 with a default setting of on/true such that Solaris-specific I/O interruption is still present as it has always been. That is, the effect of this new switch is to make Solaris-specific behavior controllable while keeping Java SE 6 behavior exactly as it was for Java SE 5 and earlier Java SE releases for Solaris.
However, this switch can be set off/false to disable Solaris-specific interruption as follows:
By setting the switch to "-" (off/false) Java SE is made to behave uniformly for all platforms with respect to thread interruption as it relates to I/O.
This switch has been documented in the Java SE release notes along with a notice that the default setting of the switch may be changed to off/false early in the Java SE 7 release cycle. That is, the plan is to eliminate this Solaris-specific behavior as the default in Java SE 7, while leaving open the choice to reenable the behavior. At the point this change is effected this and all related CRs will be declared complete.
SDN comments about this proposed change are welcome.