Hi all, I'm picking up GEODE-10479 again and reconciling my earlier plan with the work that has landed. Thanks to everyone who has moved the API cleanup forward.
GEODE-10532's HTTP status replacement is merged and resolved. The changes for 10533 and 10534 have also merged, with two identified residuals: the deprecated IndexType usage in gfsh, and the Swagger path-matching API whose replacement was deferred until Spring 6.2+. The parent still needs a fresh warning baseline and the work to re-enable deprecation/removal warnings and enforce them in CI. I also revisited Jinwoo's question on my PR #7971 for GEODE-10531. He was right to question whether removing the explicit SecurityManager check preserves subprocess permissions. OSProcess.bgexec launches through a shell, so ProcessBuilder checks that shell rather than the requested executable. A focused reproduction on Java 17 and 21 confirmed that removing the target check changes behavior for a configured policy that allows the shell but denies the target. There is also a correction to my original approach and the ticket description: these APIs still exist in Java 21, deprecated for removal. They are not the missing-API Java 21 blocker described in the ticket. I've prepared a revision that retains the explicit check and adds a removal-warning suppression only to that variable declaration, with a comment explaining the compatibility reason. It also adds a separate-JVM regression test and replaces the stale planning/checklist claims with the merged status and remaining work. This would be a proposed compatibility exception, not completion of SecurityManager retirement or of the parent issue. The focused tests pass on Java 17 and 21, and deleting the target check makes the regression test fail on both. Would a narrow exception be acceptable until we explicitly decide to retire or replace the legacy behavior? That would require updating 10531's current acceptance criteria, which ask for complete removal. If the intended direction is to retire that behavior now, I'd like to make that compatibility decision explicit before changing it. For 10479, I suggest we record agreed follow-up scope for the two residual APIs, establish a current warning baseline, and then finish warning re-enablement incrementally. We can keep the parent open until its acceptance criteria are met or explicitly revised. I'd appreciate input from Jinwoo and the contributors to 10533/10534 on that scope. Thanks, Sai PR #7971: https://github.com/apache/geode/pull/7971 GEODE-10479: https://issues.apache.org/jira/browse/GEODE-10479 GEODE-10531: https://issues.apache.org/jira/browse/GEODE-10531 GEODE-10532: https://issues.apache.org/jira/browse/GEODE-10532 GEODE-10533: https://issues.apache.org/jira/browse/GEODE-10533 GEODE-10534: https://issues.apache.org/jira/browse/GEODE-10534
