向 J2SE 应用程序添加插件支持的最佳技术?

发布于 2024-07-04 06:48:00 字数 199 浏览 10 评论 0原文

我正在编写一个 J2SE 桌面应用程序,要求其组件之一是可插入的。 我已经为这个插件定义了 Java 接口。 用户应该能够在运行时(通过 GUI)选择他们想要使用的该接口的实现(例如在初始化对话框中)。 我设想将每个插件打包为一个 JAR 文件,其中包含实现类以及它可能需要的任何帮助程序类。

在桌面 Java 应用程序中执行此类操作的最佳技术是什么?

I'm writing a J2SE desktop application that requires one of its components to be pluggable. I've already defined the Java interface for this plugin. The user should be able to select at runtime (via the GUI) which implementation of this interface they want to use (e.g. in an initialisation dialog). I envisage each plugin being packaged as a JAR file containing the implementing class plus any helper classes it may require.

What's the best technology for doing this type of thing in a desktop Java app?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

恏ㄋ傷疤忘ㄋ疼 2024-07-11 06:48:00

经过多次尝试基于插件的 Java 架构(这正是您所寻找的),我终于找到了 JSPF 是 Java5 代码的最佳解决方案。 它没有像 OSGI 这样的解决方案的巨大需求,但相当易于使用。

After many tries for plugin-based Java architectures (what is precisely what you seem to look for), I finally found JSPF to be the best solution for Java5 code. it do not have the huge needs of OSGI like solutions, but is instead rather easy to use.

温柔戏命师 2024-07-11 06:48:00

OSGI 无疑是一种有效的方法。 但是,假设您不需要卸载来重新加载插件,那么它可能会使用锤子来敲开坚果。

您可以使用“java.util.jar”中的类扫描插件文件夹中的每个 JAR 文件,然后使用“java.net.URLClassLoader”加载正确的文件。

OSGI is certainly a valid way to go. But, assuming you dont need to unload to reload the plugin, it might be using a hammer to crack a nut.

You could use the classes in 'java.util.jar' to scan each JAR file in your plugins folder and then use a 'java.net.URLClassLoader' to load in the correct one.

别理我 2024-07-11 06:48:00

如果您“只是”需要一个可插入组件,那么只需根据元信息实例化类就足够了,例如通过类加载器 META-INF/ 从类路径上或某个插件目录中的各种 jar 中读取信息。

另一方面,OSGi 提供了构建整个应用程序的方法。 如果您已经有一个大型桌面应用程序需要一个可插拔的部分,那么这将是一个陡峭的学习曲线。 如果您对桌面应用程序一无所知,OSGi 提供了模块化整个应用程序的方法。 它是关于“组件的隔离”和模块的独立性。

如果您想走上 OSGi 之路,Apache Felix 提供了一个很好的开始。 它可能看起来复杂且重量级,但这只是因为人们不习惯模块之间的这种隔离级别。 过去调用任何公共方法都很容易......

If you are "just" needing one component to be pluggable, it's enough to simply instantiate the classes based on meta information, e.g. read via a classloaders META-INF/ information from the various jars that are on your classpath or in a certain plugin directory.

OSGi on the other hand provides means to structure your whole application. If you already have a large Desktop application that needs one part pluggable, this would be a steep learning curve. If you start blank with what will be a Desktop app, OSGi provides means to modularizing the whole application. It's about "isolation of components" and independence of modules.

Apache Felix provides a nice start if you want to go down OSGi lane. It might look complicated and heavyweight, but that's only because one is not used to that level of isolation between modules. It used to be so easy to just call any public method...

め七分饶幸 2024-07-11 06:48:00

您是否考虑过使用 OSGi 作为插件框架? 使用 OSGi,您可以根据需要更新/替换、加载或卸载模块。

Did you think of using OSGi as a plugin framework? With OSGi you are able to update/replace, load or unload your modules on demand.

一指流沙 2024-07-11 06:48:00

我正在考虑的一种方法是让我的应用程序启动一个轻量级 OSGi 容器,如果我理解正确,它将能够发现指定文件夹中存在哪些插件 JAR 文件,这反过来又会让我列出它们以供用户选择从。 这可行吗?

我还找到了 Richard Deadman 的这篇文章,但它看起来有点过时(2006 年? )并且既没有提到 OSGi(至少没有提到名称)也没有提到 java.util.jar 包

One approach I'm considering is having my application start up a lightweight OSGi container, which if I understand correctly would be able to discover what plugin JAR files exist in a designated folder, which in turn would let me list them for the user to choose from. Is this feasible?

I also found this article by Richard Deadman, but it looks a little dated (2006?) and mentions neither OSGi (at least not by name) nor the java.util.jar package

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文