Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
So, what's so upsetting? It seems Sun has abandoned the "run anywhere" part of its oft-quoted write-once, run-anywhere mantra. I'll explain. The ability to "run anywhere" is predicated on a class file being able to run on any machine that has a Java virtual machine (JVM) on it, and on that VM being able to run any class file it's given. If different implementations of the JVM recognize different class file formats, platform independence is a pipe dream. Microsoft understands this issue very well. That's why it tried to push a nonconforming VM onto Windows. Programs that leverage Microsoft's nonstandard extensions simply are not platform-independent.
This standardization is particularly important in a network environment, where an application installed on a server and distributed
automatically must be able to run on all the client boxes, regardless of the VM that's installed on a given box. You can always
download a new library -- that's one of the reasons Swing is in the
javax (rather than
java) package. Updating the VM itself is another matter. Sun is well aware of this issue. James Gosling himself has often justified
changes to the language at the source-code level by saying that no VM changes would be mandated.
In the face of this fact, I was horrified to find that the Java 2 platform (formerly known as JDK 1.2) compiler can create
a nonstandard class file format recognizable only to the Java 2 VM. The class file generated by
java -target 1.2 will not run on a 1.1 VM. Since you have absolutely no control over which version of the VM is on the client platform, using this switch
effectively throws away any hope of platform independence. You'll have to ship your Java application with a version of the
Java 2 VM for every platform on which you'd hope to run, and we're back in DLL hell.
Fortunately, the switch is off by default, and you don't have to use it. But even the presence of this switch indicates that Sun is perhaps not as trustworthy as the Java community has been assuming. At a recent Java SIGs meeting hosted by San Jose's Software Development Forum, Gosling stated that even though Java has maintained backward compatibility as it has evolved, Sun has no commitment to this compatibility. He implied that there would eventually come a time where we would all be forced to adopt the new class file format. I can see it now: a Microsoft PR guy waving around a disk, shouting "Here's an official Java application, compiled with Sun's own Java compiler, and it won't run on these Windows, Solaris, or Mac boxes unless you spend hours upgrading an obscure piece of software called the virtual machine. In fact, there's no guarantee that you can even get such an upgrade if you're not running Solaris. Platform independence? Ha!"
com.holub.asynchpackage) is available in the "Goodies" section on my Web site, http://www.holub.com. The version on the Web site should be considered the definitive version -- at least it corrects any bugs I know about.
Timerclass in the JDK docs and at http://java.sun.com/products/jdk/1.2/docs/api/javax/swing/Timer.html