我们正试图确定如何为我们正在实现的服务实现一个简单的插件框架，该框架允许“插入”不同类型的计算器。
在阅读了一些关于Java插件框架的帖子之后，似乎最常见的选择是：
OSGI似乎比我们需要的更多。
“滚动你自己的”是可以的，但重用一个通用库会很好。
因此，我们归结为JPF和JSPF。JPF似乎不再处于积极开发阶段。
JSPF似乎非常简单，确实是我们所需要的一切。然而，我没有听说过太多。我只在StackOverflow上看到过一篇关于它的帖子。还有其他人对JSPF有任何经验吗？或者对这个设计选择的任何其他评论？
更新：对此不一定有正确的答案。然而，我们将采用Pavol的想法，因为我们只需要一个非常非常简单的解决方案。感谢EoH的漂亮指南。
（免责声明：我是JSPF的作者，所以最好把我的评论用一粒盐;-）
我从JSPF开始的主要原因是因为我遇到了和你现在一样的问题：我正在寻找一个简单的解决方案来使我的论文项目1）可扩展，2）给它一个或多或少清晰的代码结构。
我没有决定使用现有框架的原因是，它们中的大多数一开始就非常重量级，以至于我在阅读文档时迷失了方向，几乎忘记了我原来的任务。所以，根据你的陈述
我们正试图确定如何为我们正在实现的服务实现一个简单的插件框架，该框架允许“插入”不同类型的计算器。
我认为你可以给JSPF一个机会，看看你在一两个小时内走了多远。
但是，最终的决定也取决于您究竟想要实现的目标以及具体情况。
我从一些人那里听到了积极的结果，他们一直在使用它来构建他们的项目或在他们的项目中加载插件。另一方面，我也知道我们部门的一个人再次放弃了它，因为他觉得它与他的编程风格没有很好地融合在一起。
所以，为了简要地回答你的问题（当然是以一种有偏见的方式），我会使用
用于项目和团队的 OSGi
项目和团队的 JPF
项目和团队的 JSPF
我希望您找到最适合您的场景的插件框架。而且，无论您尝试什么，我都很乐意听到您的结果。
如果您计划只有一个（或只有几个）不是很复杂的“扩展点”，那么定义良好的SPI和一段配置可能就足够了。无需使用插件框架。
通过配置，我的意思是一些机制来找到你的插件。例如，类似或简单地在配置文件中列出您的插件。META-INF/services/
更多详情（根据要求）：
SPI = 服务提供程序接口，“API 的实现者端等效项”。要了解更多信息，请尝试搜索 API 和 SPI 之间的差异。然而，在这种情况下，它只是一个由插件实现的接口的花哨术语（即定义插件的合约）。
Ethan Nicholas的一篇很好的短文“创建服务提供商接口”描述了如何以类似的方式创建自己的SPI，就像在Java平台本身的几个部分中所做的那样。
META-INF/services/可以看作是创建SPI的一种更通用的方法。有关详细信息，请参阅 JAR 文件规范的相应部分。
