根据Mark Reinhold的twitter post，我将假设Jigsaw将成为Java 9的一部分。
在阅读Jigsaw时，我问自己一个问题：当我使用自定义模块化运行时映像发布应用程序时会发生什么，但第三方模块需要额外的JRE模块，这些模块未随应用程序一起发布，因为它们不是必需的应用程序？
想象一下想要从模块化中受益的应用程序。它提供了可由第三方模块实现的服务接口。应用程序加载所有第三方模块，这些模块在应用程序启动时提供服务接口的实现。在我看来，这是为第三方插件提供公共API的一种非常简单的方法，我可以想象我自己经常使用它。
现在，还有一个名为jlink的工具，它允许用户创建一个应用程序版本，它不仅包含应用程序模块，还包含需要的JRE模块。这称为自定义模块化运行时映像。最棒的是，该版本仅包含应用程序实际使用的JRE模块，这可以防止发布版本变得非常大。目前，jlink将确定哪些模块必须自己包含在内。但是，开发人员必须明确包含服务实现提供模块，请参阅here。我认为这对于许多开发人员不希望用户安装JRE的应用程序也很好。
当我们尝试在单个应用程序中使用两者时会出现问题：自定义模块化运行时映像仅包含应用程序使用的JRE模块。但是，插件可能使用应用程序尚未使用的JRE模块，因此这些模块在运行时不可用。因此，该插件将无法正常工作。
这是我能想到的唯一解决方案，但它远非完美：
将缺少的JRE模块包含在第三方插件中。虽然这看起来似乎是一个简单的解决方案，但实际上它有很多问题。
首先，这需要插件开发人员知道应用程序中包含哪些JRE模块。如果这是未知的，它们可能包含一个JRE模块，该模块已在应用程序本身中可用，这可能会导致问题。因此，它成为公共API的一部分，应用程序使用哪些模块。我认为这是不可取的，因为它是一个实现细节。此外，它可能会经常变化。
其次，由于可用的JRE模块是公共API的一部分，因此需要以某种方式指定它们。虽然这可能通过文档工作，但我认为它应该通过正式代码指定。例如，它可能适用于应用程序模块中的requires public子句，用于插件模块应该可用的所有JRE模块。这使得这些JRE模块可用于插件，因为插件将require应用程序模块。
第三，问题是是否需要允许插件使用额外的JRE模块。如果不是，则module-info.java可能应该有一个条款来指定当前模块是给定其他模块的插件。例如，不使用require作为应用程序模块，而是使用plugs in to或其他符号。这将阻止模块需要任何JRE模块。但是，这可能不会起作用，因为插件模块所需的其他第三方模块可能需要额外的JRE模块。因此，我认为很难为这种机制提供支持。
第四，允许插件使用额外的JRE模块也很困难。这将要求不同的JRE模块在不同版本中兼容，或者要求插件开发人员始终在与应用程序中的JRE模块版本兼容的版本中包含其他JRE模块。我不确定JRE模块是否应该在不同版本中兼容，但我的假设是它们不应该是，因为它可以防止将来发生许多变化。
我的一些假设是错的吗？也许在应用程序和插件中包含JRE模块可以正常工作？也许插件中的其他JRE模块也不必与应用程序中的JRE模块兼容？毕竟，他们可能不会互相交流。
我们该如何处理这个架构问题？是否有其他语言具有模块化和部分可释放的运行时？他们是如何解决这个问题的？
请注意，Google guava或Apache commons等常用库可能会出现类似问题。但是，这个问题应该主要是关于使用自定义模块化运行时映像所引起的问题。
我有完全相同的想法，现在已经好几天了。这个问题似乎没有任何好的资源。我的想法是一个自定义框架。该框架可以允许第三方模块通过使用配置文件来请求其他依赖模块。然后，如果模块将安装到应用程序中，框架将决定（可以通过用户交互完成）。 JRE模块可以直接安装到JRE模块文件夹中，其他模块可以复制到自定义文件夹中以便于维护。但是这个解决方案需要Oracle的一些端点，允许开发人员下载单个jmod文件。