Resolving as "Won't Do", since my original suggestion was to bump the Java version (to 8 from 7) in a minor release. The Java Product Version Policy has been updated to include the statement that minor releases have the same Java source and target level.

I'll close later pending any comments.

(I'm also deeply skeptical that in fact most of the fixes really make it into OpenJDK, but the recent bug should be instructive on that question.)

FWIW: the July OpenJDK 7 updates from both Red Hat and Ubuntu include the "fix" for CVE-2015-2625 (aka "8067694: Improved certification checking").

Except that we can't test or support a half-dozen OpenJDK variants, and they've already proven to be unreliable in practice over and over again. That really is a problem to me unless we specifically limit support to Red Hat / CentOS. I don't really know that that helps people much, so that's the trade off here.

(I'm also deeply skeptical that in fact most of the fixes really make it into OpenJDK, but the recent bug should be instructive on that question.)

Sure. I don't care if this issue is about Windows platform only.

If we can't access it, we can't support it.

Exactly. I just want to say OpenJDK seems like importing upstream (Oracle) internal security patches, and so do Linux distributions.

From an open source project perspective, I consider Java 7 EOL just like RHEL 4 is. If we can't access it, we can't support it. That's what triggered this issue, we have no official policy on handling the EOL question and we definitely need one. The SP policy has been pretty well-baked on this for a while.

For myself, I do not consider the existence of OpenJDK to alter that calculus, because my opinions about OpenJDK aside, that doesn't address Windows (not practically speaking, I realize in theory it can get built). Of course, one option is to fork the policy.