One of the most fundamental design principles of Java is captured in its motto "Write Once, Run Anywhere." It describes how a .class file encodes its instructions at the bytecode level, allowing portability between different machines that, through a specific virtual machine implementation, resolve the bytecodes into executable instructions to give the program life. It's a goal that's almost enshrined in the Java fundamental commandments, as Sun took out a high-profile advertising campaign to back up the "100% Pure Java" slogan and engaged Microsoft in battle for their proprietary language extensions.
Another fundamental design principle of Java is that functionality cannot be removed, so a program compiled to run on one version of a Java Runtime Environment (JRE) is able to run on future versions without re-compilation. The idea behind this is that as users upgrade their machine's JRE, they can be confident that none of their Java software will stop working because an API it relied on was removed.
Ten years on from Java's inception, however, I question whether both of these goals are still relevant in theory or practice.
A large amount of the Java code that I can think of was built against a specific JRE level that was then shipped with the product. This makes sense in a commercial environment where you need to diligently test the product against a set of scenarios and then provide some kind of guarantee to users that the software will execute on their machine with the same resilience as it did in the system test environment. This kind of assurance is best underwritten by shipping the same version of the JRE that the product was built and tested against. When it comes to different operating systems and platforms, you typically find different download packages and separate builds, so at some part of the process the "write once, ship everywhere" commandment almost always gets broken.
On one level it seems a shame when you have to bundle a JRE with a product to ensure it's going to work in the field, but it's a practice that's common among those who are allowed to do so. Doing so increases one's footprint, making installation more complex as well as possibly precipitating a specific license agreement, depending on the kind of product being created. However, you only have to look at the number of Java products that include their own /jre/ directory to see that this is a widespread practice. In the products I've worked on where we include a JRE, the development team always get criticism from users who try to hack around the /jre/ directory and attempt, usually unsuccessfully, to perform their own upgrade. Telling said irate users to wait for the product version that contains an officially upgraded and tested JRE frustrates them; however, it's easier than dealing with people who can't get the original product to work at all because the system JRE is at the wrong level and requires upgrading.
There is no malice or conspiracy theory involved with shipping and not allowing replacement of a product's JRE. It simply is a way of underwriting the finished product as being a complete solution. I recently had to work on version 2.0 of a product whose version 1.0 manual told the user to download about 40M of open source from a number of possible sources, then another 20M of JRE, before unzipping the 2M product onto the directory structure in the correct place. For version 2.0 as well as working on the release's functional line items, we changed it to include every piece of runtime stack it needed to sit on top of the operating system. Our users were ecstatic that they no longer had to sticky tape the solution together by themselves.
A friend of my brother's recently asked me to fix a copy of their very slick, Java-based peer-to-peer file-sharing software. The fix involved downloading a back level of the JRE that, ironically, their support forums insisted had to come from a specific JRE vendor before the product would even bring up the splash page. All of this incompatibility and futzing around with "Get Java Now" icons doesn't help to promote the image of Java in the users' minds; rather it poisons their experience and reinforces their perception that Java is something complex that causes install and upgrade headaches. Likewise I've never been a fan of "Java" splash screens on my phone - ironic given I'm a huge fan and proponent of all things Java, but I, like the desktop user who has to struggle and upgrade/downgrade/hardcode the JRE version, want my computer to do the job that I ask it to do without a commercial break from my spark plug vendor as I attempt to negotiate rush hour traffic.