我已经阅读了几篇在 jdk 9 中删除 .* API 的文章。删除是否意味着它们已从 jdk 9 中完全删除，或者它们被标记为已弃用？
鉴于上述陈述，如果项目是 jdk 8 编译的，它会在 jdk 17 上运行而没有任何问题吗？我是第一次尝试这个，并且由于模块化更改，tomcat 无法支持 jdk 8。
我计划在 jdk 8 中编译，然后在 jdk 17 上运行，直到整个项目符合 jdk 17 （通过 jdk 17 兼容，我的意思是使用更新的 API，而不是现有的 jdk8 已弃用的 API）。
我是否朝着正确的方向前进？还是我应该采用不同的迁移方法？
删除是否意味着它们已从 jdk 9 中完全删除，或者它们被标记为已弃用？
有些刚刚被标记为已弃用。其他的已被完全删除。虽然一般不在 Java 9 中。大部分删除是在以后完成的，有些仍然会发生。如果您查看现在注释为 的元素，则@Deprecated在某些情况下，注释将正式表明该元素将被删除。
鉴于上述陈述，如果项目是 jdk 8 编译的，它会在 jdk 17 上运行而没有任何问题
不必要。发生的另一件事是对“内部”Java SE API 的访问已逐渐关闭。因此，如果您的应用程序使用这些 API，在 Java 9 中您会收到警告，在 Java 11 中默认情况下您会收到错误，而在 Java 17 中，某些访问（我认为）变得不可能。
所以......可能会有“问题”。
迁移的正确方法就是这样做。测试，测试，测试，直到你解决所有问题。
显然，这意味着你需要一个测试服务器，并且你需要使用一个自动化的测试框架，包括单元测试、功能测试、UI 测试等等。但这些只是很好的软件工程实践。你应该已经在关注他们了。
我计划在 jdk 8 中编译，然后在 jdk 17 上运行，直到整个项目符合 jdk 17（通过 jdk 17 兼容，我的意思是使用更新的 API，而不是现有的 jdk8 已弃用的 API）。
我是否朝着正确的方向前进？还是我应该采用不同的迁移方法？
不。正如@Holger 指出的那样，由于Java 17 编译器已经识别出的问题，您可能会遇到很多运行时错误。
只有一种方法……真的。在 Java 17 上编译，直到确定所有编译时依赖问题；即使用已被删除或关闭的 API。然后在 Java 17 上运行并测试、测试和测试，直到发现所有其他问题。
在开始之前，建议检查项目的所有依赖项（库等）以查看 Java 17 是否支持它们。然后将它们更新为正确的（可能是最新的）版本。
Java 17 仅发布了几周，因此您的某些依赖项很有可能还没有赶上。如果是这样的话，在这个阶段以 Java 11 LTS 为目标可能是一个更好的主意。