Java插件框架选择

Java plugin framework choice

提问by Marcus Leon

We're trying to determine how to implement a simple plugin framework for a service we are implementing that allows different types of calculators to be "plugged-in".

我们正在尝试确定如何为我们正在实现的服务实现一个简单的插件框架，该框架允许“插入”不同类型的计算器。

After reading a numberof posts about Java plugin frameworks, it seems like the most common options are:

在阅读了许多关于 Java 插件框架的帖子后，似乎最常见的选项是：

• OSGI
• "Rolling your own" plugin framework
• The Java Plugin Framework(JPF)
• The Java Simple Plugin Framework(JSPF)

• OSGI
• “滚动你自己的”插件框架
• 该Java插件框架（JPF）
• 在简单的Java插件框架（JSPF）

OSGI seems to be more than we need.

OSGI 似乎比我们需要的更多。

"Rolling your own" is ok but it would be nice to reuse a common library.

“滚动你自己的”是可以的，但重用一个公共库会很好。

So we're down to the JPF and JSPF. JPF doesn't seem to be in active development anymore.

所以我们归结为 JPF 和 JSPF。JPF 似乎不再处于积极开发状态。

JSPF seems very simple and really all we need. However I haven't heard much about it. I've only seen one poston StackOverflow about it. Does anyone else have any experience with JSPF? Or any other comments on this design choice?

JSPF 看起来非常简单，而且确实是我们所需要的。然而，我并没有听到太多关于它的消息。我只在 StackOverflow 上看到过一篇关于它的帖子。有没有其他人对 JSPF 有任何经验？或者对这个设计选择有任何其他评论吗？

---

---

Update: There isn't necessarily a correct answer to this.. however we're going to go with Pavol's idea as we need just a really, really simple solution. Thanks EoH for the nice guide.

更新：这个问题不一定有正确答案..但是我们将采用 Pavol 的想法，因为我们只需要一个非常非常简单的解决方案。感谢 EoH 的精彩指南。

采纳答案by Pavol Juhos

If you are planning to have just one (or only a few) not very complex 'extension points' than perhaps a well-defined SPI and a piece of configuration might be sufficient. No need to use a plugin framework.

如果您计划只有一个（或只有几个）不是很复杂的“扩展点”，那么定义明确的 SPI 和一段配置可能就足够了。无需使用插件框架。

By piece of configuration I mean some mechanism to find your plugins. For example something like META-INF/services/or simply listing your plugins in a configuration file.

通过配置，我指的是一些找到插件的机制。例如类似META-INF/services/或简单地在配置文件中列出您的插件。

More details (upon request):

更多详情（应要求提供）：

SPI = Service Provider Interface, an "implementer-side equivalent of an API". To learn more try searching for a difference between API and SPI. However in this context it is just a fancy term for an interface to be implemented by your plugins (i.e. defines the contract for your plugins).

SPI =服务提供者接口，“API 的实现者端等价物”。要了解更多信息，请尝试搜索 API 和 SPI 之间的差异。然而，在这种情况下，它只是一个由插件实现的接口的花哨术语（即定义插件的合同）。

A nice, short article "Creating a Service Provider Interface" by Ethan Nicholas describes how to create your own SPI in similar way as it is done in several part of the Java Platform itself.

Ethan Nicholas撰写的一篇不错的简短文章“创建服务提供者接口”描述了如何以与在 Java 平台本身的多个部分中完成的方式类似的方式创建您自己的 SPI。

META-INF/services/can be seen as a more generalized approach to creating SPIs. More information can be found in the respective section of the JAR File Specification.

META-INF/services/可以看作是创建 SPI 的一种更通用的方法。更多信息可以在JAR 文件规范的相应部分找到。

回答by EoH

(Disclaimer: I am the author of JSPF, so better take my comment with a grain of salt ;-)

（免责声明：我是 JSPF 的作者，所以最好对我的评论持保留态度 ;-)

The main reason I started with the JSPF was because I had the same problem as you have now: I was looking for a simple solution to make my thesis-project 1) extensible and 2) give it a more or less clear code structure.

我开始使用 JSPF 的主要原因是因为我遇到了和你现在一样的问题：我正在寻找一个简单的解决方案来使我的论文项目 1) 可扩展和 2) 给它一个或多或少清晰的代码结构。

The reason why I haven't decided to use an existing framework was because most of them were so heavyweight to start with, that I got lost in reading documentation and was almost forgetting my original task. So, according to your statement

我之所以没有决定使用现有框架，是因为它们中的大多数一开始都非常重量级，以至于我在阅读文档时迷失了方向，几乎忘记了我最初的任务。所以，根据你的说法

We're trying to determine how to implement a simple plugin framework for a service we are implementing that allows different types of calculators to be "plugged-in".

我们正在尝试确定如何为我们正在实现的服务实现一个简单的插件框架，该框架允许“插入”不同类型的计算器。

I'd think that you could give JSPF a shot and see how far you come within one or two hours.

我认为你可以试一试 JSPF，看看你在一两个小时内能走多远。

However, the final decision also depends a bit on what exactly you want to achieve, and the specific circumstances.

但是，最终的决定还取决于您究竟想要实现什么以及具体情况。

I have heard positive results from a number of individuals who have been using it to structure their projects or load plugins in their projects. On the other hand, I also know of one person in our department who discarded it again because he didn't feel it was mixing well with his programming style.

我从许多使用它来构建项目或在项目中加载插件的人那里听到了积极的结果。另一方面，我也知道我们部门的一个人再次放弃了它，因为他觉得它与他的编程风格不太相配。

So, to answer your question briefly (and surely in a biased way), I would use

因此，为了简要回答您的问题（并且肯定以有偏见的方式），我会使用

OSGifor projects and teams

用于项目和团队的OSGi

• which are large and have many people working on it
• that justify the overhead of setting up the infrastructure
• in need of the specific services offered

• 很大，有很多人在做这件事
• 证明建立基础设施的开销是合理的
• 需要提供的特定服务

JPFfor projects and teams

项目和团队的JPF

• of medium size (?, honestly I am not sure about the project / team size they are targeting)
• which are in need of more structured facilities to organize their code, like XML configurations, detailed plugin lifecycle management, extensible plugins ...

• 中等规模的（？，老实说，我不确定他们针对的项目/团队规模）
• 需要更结构化的工具来组织他们的代码，比如 XML 配置、详细的插件生命周期管理、可扩展的插件......

JSPFfor projects and teams

项目和团队的JSPF

• of small size, following an agileparadigm
• that just need something that works out of the box, without the need of configurations or setup
• willing to sacrifice some features for simplicity

• 体积小，以下内容的的敏捷范例
• 只需要开箱即用的东西，无需配置或设置
• 愿意为了简单而牺牲一些功能

I hope you find the plugin framework most suitable for your scenario. And, no matter what you try, I would be happy to hear about your results.

我希望您找到最适合您的场景的插件框架。而且，无论您尝试什么，我都会很高兴听到您的结果。

回答by Faz

If you need a really simple solution, try jin-plugin. It is a minimalistic plugin framework for Java and PHP.

如果您需要一个非常简单的解决方案，请尝试jin-plugin。它是一个适用于 Java 和 PHP 的简约插件框架。