[skrebbel]

Maybe JDK X+1 had gone through a deep and thorough review at some point that got it put on some "OK" list somewhere? And maybe X+2 was too new to have made it through that same deep and thorough review. It makes sense from an auditor's perspective, maybe X+2 has new bugs that X+1 didn't have. They want the good version, not the newest version.

[loup-vaillant]

Maybe. Doubtful in practice, though.

[NovemberWhiskey]

Actually it's super-realistic in practice, especially the JDK, given the short-short-long support duration cadence for JDK releases. e.g. I am totally uninterested in someone telling me I need to use JDK 12 rather than JDK 11: the former is already out of support and the latter will be supported until at least 2026.

[dyu]

They could be referring to the list of FIPS-validated crypto modules.

[ryandrake]

OP's story and the article's author are kind of missing the point. These are both simple stories of a vendor failing to meet a [presumably] written requirement: The customer, or regulator, required X, and vendor decided instead to provide Y, and then were dumbfounded when that was deemed unacceptable. OP's vendor went farther, offering Z instead, and the customer again reminded them that X was required. It doesn't really matter if there are better alternatives than X. Those alternatives are not part of the requirement.

Whether Y=X-1 or Z=X+1 is irrelevant. Customer requires X, you provide X or they'll find another software vendor.