Also, I have another gripe. I was reminded of this as I was installing
the new Java 8 bits, and I temporarily removed the older Java 8 version.
C:\Users\Brenden\Dev\proj\Test2\build\classes>java -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
C:\Users\Brenden\Dev\proj\Test2\build\classes>
C:\Users\Brenden\Dev\proj\Test2\build\classes>java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b129)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b69, mixed mode)
This is before and after. Notice that the Java 7 version is not updated
(it should be update 51, I think, not 45). Your updater fails to update
an older version if it detects a newer version of Java. That is, if the
updater sees Java 8 is installed, it won't ever update Java 7 to the
latest patch level. In light of all the recent bad press Java has
received because of security issues (especially not updating older
versions of Java) I think this is unacceptable.
Always, always, always update a version of Java if is possible to do
so. Sure, don't make an old version of Java the default installation,
but please update the bits that are sitting on the disc. There's really
no good reason not to, and if this sort of scenario ever happens (a user
uninstalls a current version to expose an older version) you're left
with known bad bits running on a live installation. I hope I don't have
to expound on how lousy an idea that is.
When you do update an older version, you need to check if *any* part of
that version is still in use. For example, I don't think the Java 8 RC
installs a browser plug-in, so I'm still actually using an (unupdated,
old, u45) Java 7 plug-in. Getting the most recent plug-in updated to
all browsers should be a high priority during a Java update.
Thanks again for reading my little missive.
On 2/11/2014 2:31 PM, mark.reinh...@oracle.com wrote:
Last week a serious flaw in a new API was reported [1]. We decided to
fix that bug, along with an unrelated JCK failure on Mac OS X [2], so
we now have a second JDK 8 Release Candidate, build 129.
Binaries available here, as usual: https://jdk8.java.net/download.html
