Java now has a built-in expiration date. What that's about (not obvious at first)

Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

This may be of interest to those who have chosen to configure CF to use that a an updated JVM over what it comes with, which is something I discussed in more detail in a blog entry back in 2011, when Adobe first permitted us to do that for CF 8 and 9, CF911: Have you updated your #ColdFusion JVM to _24 yet? Important security fix for CF 8/9 (and the concept and approach to updating your JVM still applies to CF10. That said, to update CF 9 or 10 to Java 1.7, you do need to apply a certain CF update first. More at articles like this one by Ben Forta, offered at dzone.)

So what's this Java 1.7 JVM update "expiration date" about?

First, let's get this out of the way: it's not that the JVM will stop working on that date.

Rather, on the one hand this "expiration date" does tell us first, as readers of that document, that we should regard that particular update to be (in Oracle's mind) no longer as updated as it could be, after that date.

But more important, what it's really about is it's supporting the automated mechanism in the JRE, which would normally watch out for new updates from Oracle, to report to users (via a desktop notification) if there were any available updates.

If that check can't reach the internet for some reason, Oracle didn't want users to mistakenly assume that their JVM was reasonably updated. So now if it can't reach the internet to check, that desktop notification feature will automatically report that to users. Again, though, it won't affect CF's use of that Java runtime.

How did I find this out? And where can you learn more?

The reference in update 21

Well, while the "expiration date" is indeed referenced in that technote for 1.7.0_21, there's no real explanation of its purpose, which is what started me on this treasure hunt myself. It just says:

JRE Expiration Date

The expiration date for JRE 7u21 is 07/18/2013.

And curiously there is no mention of any expiration date in the 4 previous JVM updates, 17, 15, 13, and 11. More on that in a moment.

The first (and more elaborated) reference in 1.7 Update 10

But if you look at update 10 (1.7.0_10), its technote does explain it:

JRE Expiration Date

The JRE relies on periodic checks with an Oracle Server to determine if it (the JRE)is still considered up-to-date with all the available security fixes (above the security baseline). In the past, if the JRE was unable to contact the Oracle Server, it continued to behave as though it is still the most recent version with regard to security, for an indefinite period.

To avoid this problem, a secondary mechanism, that does not rely on external communication, has been added to the JDK 7u10. From this release onwards, all JREs will contain a hard-coded expiration date. The expiration date is calculated to end after the scheduled release of the next Critical Patch Update.

This means that JREs that are unable to contact Oracle Servers for an extended period of time, will now start offering additional protection after a reasonable period, and will not continue to behave as if they were still up-to-date with security fixes.

Ok, that makes sense. Given the big scare of JVM security holes a few months back (primarily of impact to those using Java in browsers, rather than those using it on servers), where the US Govt even warned people to disable Java in their browsers until the hole was patched, it made sense for Oracle to respond with an improved means of notification (not that it will satisfy everyone, of course.)

Why no expiration dates for updates 11, 13, 15, and 17; only for 21?

Still, it is indeed curious that the intervening JVM updates between 10 and 21 don't mention any expiration date.

We might assume that perhaps it's that the subsequent updates didn't have security fixes, but that's not the case. The very next one, 11, did mention in its technote that it fixes "security vulnerabilities". It also listed itself as the new "security baseline" for java 7 at the time of its publication.

So I would think that it should have had an expiration. I suspect it did, tracked internally in its files, even if not mentioned in its technote. But I'll leave that for others to explore. Indeed, you can learn more about how that date is tracked, and what some are doing to deal with the nuisance of these alerts to their end users, in in this Symantec discussion forum.

Again, this will NOT cause any prompt to CF users

To repeat, we who might use an updated JVM in ColdFusion do NOT need to worry about this expiration date causing any prompts to our users. That prompting is to the desktop user who has installed Java.

So while your CF server admin may see such a prompt on the server, your end users will not see any such prompt based on your having update Java on the server and not updated it again after that expiration date. I don't suppose too many people would have worried about that, but as long as some might, I did want to get that out of the way.

Conclusion

But I point all this out because again while the expiration date WAS mentioned in the current latest update's technote above (Update 21, as I write), it did NOT have any explanation at all, and i just wondered what it was about. And I only found it by digging further and finding the explanation in Update 10 (I also have searched the Oracle technote site and find no other explanation of it except in that one technote), so I thought I'd share the info here.

This is similar to what happened with CF and its hotfixes: if you don't know to go back and look in previous hotfix technotes, you might miss some important things that may apply, even if (especially if) you jump to a later one. For more on that issue, with respect to CF hotfixes, and a new document that lists important notes from past hotfix technotes, see my blog entry from a couple of weeks ago, "CF911: New Adobe document about #ColdFusion security hotfixes: required reading, I'd say".

Let me know if you found this info on the expiration date helpful, nor or on finding it in the future. :-)

For more content like this from Charlie Arehart:

• Signup to get his blog posts by email:
• Follow his blog RSS feed
• View the rest of his blog posts
• View his blog posts on the Adobe CF portal

Need more help with problems?

• If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
• See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed