为何JEP 425中Thread.ofVirtual()与Thread.ofPlatform()如此命名？

你提到的《Effective Java》中对of静态工厂方法的定义是：

一种接受多个参数并返回整合了这些参数的该类型实例的聚合方法

而JEP 425里Thread.ofVirtual()和Thread.ofPlatform()返回的是对应类型的构建器（Thread.Builder.OfVirtual/Thread.Builder.OfPlatform），并非直接返回Thread实例，这确实和传统of方法的典型用法有差异。

以下是这种命名方式的设计考量：

• API简洁性与直观性：Loom项目的核心目标之一是清晰区分虚拟线程与平台线程，ofVirtual()/ofPlatform()的命名能让开发者一眼明确后续构建的线程类型，相比virtualThreadBuilder()这类冗长命名，更符合Java API一贯的简洁风格。
• 命名惯例的灵活适配：Java标准库的命名规则并非完全僵化，会根据API的设计场景调整。这里的ofXxx()本质是限定类型的构建器入口，而非传统意义上的聚合实例工厂，这种设计延续了Java中“通过静态工厂暴露构建器”的模式，比如Files.lines()这类方法也是通过静态工厂返回中间对象而非最终结果。
• API体系的连贯性：这种命名方式让线程构建API和Java其他构建器风格的API保持了逻辑一致，开发者可以沿用“入口方法+链式构建”的使用习惯，降低学习成本。

另外，你无需担心提问会被指责纠结细节——命名是API设计的核心环节，直接影响开发者的理解效率和使用体验，这类疑问本身就是推动Java API优化的重要部分，你的关注完全合理。

内容的提问来源于stack exchange，提问作者user2418306