Java 在不向客户端应用公开依赖项的情况下使用Spring

我正在为几个客户机编写一个JavaAPI，我希望在内部使用Spring及其一些特性，但我不想向客户机公开我的依赖项

这可能吗

因此，如果我的客户机使用不同版本的spring，它们将与我的内部spring依赖项隔离

如果是这样的话，我的spring依赖项是否会在jar内部绑定？我的客户端应用程序是否需要自定义类加载器

我听说您可以通过OSGI捆绑包使用它，但我想知道这是否能满足我的要求

---

我的API的客户端不会启用OSGI，或者我们当前没有使用OSGI捆绑包的环境。

这样做实际上是不可行的，或者说是不可取的。为什么要“隐藏”依赖项？您是否还想隐藏对您可能正在使用的任何日志记录包的依赖关系（例如）

如果您的实现中有依赖项，那么最好将它们发布，因为这将大大减少API用户的痛苦，因为他们甚至在尝试使用您的代码之前就知道可能存在哪些冲突

别忘了，您的用户实际上是开发人员，我相信他们更愿意预先了解任何地雷或需求

编辑-关于OSGi:

---

OSGi肯定会解决您的相互冲突的依赖性问题，但它也依赖于在OSGi环境中进行部署，您没有提到客户机的情况。此外，仍然不建议在捆绑包中“隐藏”这些依赖项。OSGi的本质就是允许那些相互关联的依赖项在同一个应用程序中共存。

隐藏依赖项可以消除以下问题：这个“jar”将为我带来什么，它将与我的“X”版本冲突。示例1）客户机应用程序使用Spring2.5，而我在内部使用Spring3.0。我不想强制客户端升级。其目的是将依赖项内部化，以便客户机不关心内部引用的内容。在我的例子中，我们有spring客户机和非spring客户机，但我现在不想直接告诉他们，去加载一个上下文并包含40个新的JAR以使用我的API。只是想知道这在Java中是否很容易实现。这实际上是不可行的。OSGi可以提供帮助，但这将迫使您的客户机使用OSGi，或者您必须将OSGi嵌入到您的实现中（从未这样做过，但我相信这是可行的-Neil可能会证实）。基本上，您必须尝试某种类加载器操作来隐藏这些依赖项。接下来的问题是，当在任何依赖项中发现bug时，您必须重新部署lib，而不是简单地让您的客户机获得spring3.0.1（例如）。我认为从长远来看，这会使您的解决方案更加复杂和脆弱。Robin-我同意，使用OSGi实现这一目的是基于在OSGi环境中实际运行。此外，如果只是出于问题中所述的原因，我不会建议OP改变他的环境。另一方面，如果他确实在OSGi上构建，并使用它向API的消费者隐藏实现细节，那么从长远来看，他最终会得到一个简单、稳定、不那么脆弱的解决方案。@Neil-我同意，但他没有说任何他客户正在使用OSGi的意思。我想不会，因为我认为如果他们真的这样做的话，他已经走了这条路。当然，即使OSGi是可以接受的，我仍然不建议“隐藏”依赖项，因为这基本上需要将依赖项打包到他自己的包中，可以说是隐藏的。依赖项仍然应该公开，但由于版本控制而导致的类加载问题将消失。@Robin-是的，我同意：他或他的客户可能没有使用OSGi，因此他不能依赖涉及OSGi的解决方案。对于第二部分，我有点同意。他的捆绑包的依赖项应该是明确的，以便部署人员可以管理它们，但它们不应该通过他的导出API公开。OSGi当然可以帮助做到这一点，因为Spring将成为捆绑包的内部实现细节。您可以使用Spring DM或Blueprint之类的工具来公开捆绑包中的服务，而客户端捆绑包将绑定到这些服务，而不知道实现细节。只有在您未指定的OSGi环境中部署时，OSGi才有帮助。你能详细介绍一下你的API是如何使用的吗。我假设它被用作其他应用程序的库，这是否正确？取决于您希望使用的Spring功能。如果您计划使用

JdbcTemplate

或

@Autowired

，那么您无法避免对Spring的依赖，因为它将是编译时依赖。如果您计划只使用IoC，那么就可以避免对Spring的依赖。