Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Programming Java threads in the real world, Part 5

Has Sun abandoned 'run anywhere'? Plus: Threads and Swing, timers, and getting around stop(), suspend(), and resume() deprecation

By Allen Holub, JavaWorld.com, 02/01/99

Whatever happened to 'run anywhere'?

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!"