If a flag is declared in the flag table to become obsolete in JDK N then as soon as we switch to version N we start ignoring the flag. That can cause tests using the flag to fail and this can impact nightly testing significantly.

I don't think it is reasonable to expect all the obsoletion work related to a flag to happen immediately upon a version update. So I think that until the flag (and related code) is actually deleted from the source code, the fact it is recorded as "obsolete" should trigger a temporary warning:

Warning: UseXXX is marked for obsoletion in this release of the JDK

and we continue to process the flag as in the prior release.

However we still need to ensure we don't ship a release where we forgot to do the actual obsoletion of a flag that was listed as obsolete. Not sure how to handle that ...

Update: after further discussion it has been proposed that we use the build number as the trigger for a whitebox or gtest that performs the currently disabled full verification of the flag table. So if a flag has not be obsoleted or expired as it should by build N** then we fail the gtest. This will complement the relaxing of the obsoletion check at the start of the release cycle.

** the value of N is TBD but given a 6 month release cycle and approximately weekly builds then we can easily pick a good value. 20 seems good - should be ~2/3 through the release but before RDP2.