这并不是 OSGi 的真正意图。如果一个包有一些东西要添加到“全局”上下文中，你应该注册一个服务。所以每个有东西要共享的包都可以在自己的 start 方法中做到这一点。
然后其他一些组件（DS、ServiceTracker、Blueprint 等）可以监听这些事件，并采取相应的行动。
这非常重要，如果您开始手动搜索所有捆绑包，您将完全失去 OSGi 的优势。
您的捆绑包在启动时通过捆绑激活器获得控制权，或者更好的是通过 DS。那时它可以向服务注册表注册服务，以便其他人可以找到/使用它们。
您计划走的路线（命名类的属性）是邪恶的，因为您无疑将在类加载地狱中运行。模块化就是隐藏你的实现细节，你的实现类的名字就是这样的细节。
在属性文件中公开实现类是非常糟糕的做法，它失去了模块化的优势。另一个类是否引用您的实现类或属性文件都没有关系，问题在于 impl. 类暴露。
不幸的是，这种模式在我们的行业中变得如此普遍，以至于许多开发人员认为这是正常的 :-(
OSGi 允许您以只允许在模块内部知道实现类的方式共享接口类型的实例。
就像之前写的一样，你应该尝试使用服务来实现你想要的。我猜你有一个接口应该可以在运行时安装一个或多个实现。因此，如果您控制实现接口的包，那么只需让它们通过使用 Activator 或蓝图上下文将其实现安装为服务。您可以使用服务属性来描述您的实现。
然后，需要实现的包可以使用服务跟踪器或蓝图中的服务引用来查找服务。
如果这是不可能的，那么您可以使用包上下文来获取正在运行的包并实例化类，但这不是 OSGi 应该工作的方式。您将遇到类加载问题，因为尝试实例化类的包将无法直接访问它们。