[11u] RFR/RFA (S): 8253134: JMM_VERSION should remain at 0x20020000 (JDK 10) in JDK 11

[Volker Simonis]

On Mon, Sep 14, 2020 at 11:25 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Please review this patch and CSR for 11.0.9. If approved, I propose tagging the issue with jdk11u-critical-request.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8253134
> CSR: https://bugs.openjdk.java.net/browse/JDK-8253136
> Webrev: http://cr.openjdk.java.net/~phh/8253134/webrev.11u.00/
>
> JDK-8231209<https://bugs.openjdk.java.net/browse/JDK-8231209>, which was originally pushed to JDK 14, has been backported to 11.0.9 and 11,0.10-oracle. Those backports changed JMM_VERSION from 0x20020000 (JDK 10) to 0x20030000 (JDK 14), which introduced an incompatibility that was overlooked in the backport CSRs JDK-8247807<https://bugs.openjdk.java.net/browse/JDK-8247807> (11.0.9) and JDK-8248871<https://bugs.openjdk.java.net/browse/JDK-8248871> (11.0.10-oracle). JDK 11 users checking for JMM_VERSION == 0x20020000 will find 0x2003000 instead and possibly abort. The issue was first noticed as part of reviewing a backport of JDK-8185003<https://bugs.openjdk.java.net/browse/JDK-8185003> to JDK 8: see the Description in the corresponding CSR JDK-8251498<https://bugs.openjdk.java.net/browse/JDK-8251498>.
>
> For the reasons detailed there, JMM_VERSION in JDK 11 should be reverted to 0x20020000 (JDK 10), and the @since javadoc tag for com.sun.management.ThreadMXBean.getCurrentThreadAllocatedBytes should be changed from 14 to 11.0.9. If/when the JDK-8231209<https://bugs.openjdk.java.net/browse/JDK-8231209> backport to JDK 8 is approved for openjdk8u282, the @since tag should be changed to 8u282.
>

This all looks good to me. I've also reviewed and endorsed the CSR.

I'm only not sure about the last sentence: "If/when the JDK-8231209
backport to JDK 8 is approved for openjdk8u282, the @since tag should
be changed to 8u282". Not sure if we should really do that? If
somebody reads that in jdk11u he could think that the change must be
in 11.0.0 and later as well, but that's not true.

If somebody reads it in the 8u282 API he might think the same (and
that it is in 9 & 10 but those two are hopefully not used by anybody
any more), and there's no way to fix that. But I'd personally leave it
as 11.0.9 in jdk11u.

Best regards,
Volker

> Thanks,
> Paul
>