对于如何命名包含使用外部版本化 API 的类的 Java 包是否有任何约定？
假设我们有一个服务的主要-次要语义版本控制方案，并且我们必须实现一个与该 API 的特定版本兼容并绑定(bind)到该 API 的特定版本的使用者。命名包(和类)的最佳实践是什么？
目前，我们使用的方案为:${service}_${M}_${N}(M = 主要版本，N = 次要版本)。例如:com.example.theService_1_0.。
但 sonarqube 提示它不符合惯例。
当然我可以禁用这个规则，但我想知道是否有任何最佳实践？
我正在寻找一种通用方法，而不仅仅是 REST 特定的方法，因为我遇到过 WebService、REST 和 CORBA 的消费者实现。我不确定，工件版本控制(如在 Maven 中)在这里是否有效，因为它与实现的版本有关，而不是 API 的版本。
我知道关于 api versioning 有疑问，但这些是关于生产者的，而不是消费者。
最佳答案
是的，Java 包名称有一个强烈且不明确的约定来指示依赖项的版本:不。
如果您将应用程序更改为使用新版本的外部 API，则您将创建新版本的应用程序。您要查找的版本号是您的应用程序的版本号。在许多 Java 项目中，依赖项的版本由 Maven 配置文件管理。
无论如何，当类使用特定的 API 版本时，类和包名称没有必要公开此信息，这会违反封装性。这些名称有不同的用途。
请注意，当您使用 HTTP/REST API 或 Java API 时，这没有什么不同。毕竟，我认为您不会将您的类命名为 TheServiceWithLog4J_12_1_5。至少我希望不会。
您没有提到您是否需要同时支持此外部 API 的多个版本。即使您这样做了，我仍然不建议在包名称中公开 API 版本号。相反，请使用包名称来指示为什么您有两个版本以及重要的区别。
关于用于版本控制外部 API 的 Java 包命名，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42900780/