问题描述
摘要
在一些机器从 JDK 11.0.10-
更新到 JDK 11.0.11+
之后,我们的构建管道被破坏了。这是由于更改了 jdeps
行为所致。经过一些研究后发现,这可能是由于 JDK-8214213
引入的更改:
假设我们正在检索 sentry-1.7.25.jar
的依赖项,那么我们通过 CLI 对 jdeps
的用法如下:
jdeps --list-deps -filter:module --multi-release=11 "..\somePath\sentry-1.7.25.jar
生成的依赖项列表如下所示:
11.0.10
及以下
java.base
java.logging
java.naming
11.0.11
及以上
Error: Missing dependencies: classes not found from the module path and classpath.
To suppress this error,use --ignore-missing-deps to continue.
sentry-1.7.25.jar
io.sentry.event.helper.BasicRemoteAddressResolver -> javax.servlet.http.HttpServletRequest not found
io.sentry.event.helper.ForwardedAddressResolver -> javax.servlet.http.HttpServletRequest not found
io.sentry.event.helper.HttpEventBuilderHelper -> javax.servlet.http.HttpServletRequest not found
io.sentry.event.helper.RemoteAddressResolver -> javax.servlet.http.HttpServletRequest not found
io.sentry.event.interfaces.HttpInterface -> javax.servlet.http.Cookie not found
io.sentry.event.interfaces.HttpInterface -> javax.servlet.http.HttpServletRequest not found
io.sentry.servlet.SentryServletContainerInitializer -> javax.servlet.ServletContainerInitializer not found
io.sentry.servlet.SentryServletContainerInitializer -> javax.servlet.ServletContext not found
io.sentry.servlet.SentryServletContainerInitializer -> javax.servlet.servletexception not found
io.sentry.servlet.SentryServletRequestListener -> javax.servlet.ServletRequest not found
io.sentry.servlet.SentryServletRequestListener -> javax.servlet.ServletRequestEvent not found
io.sentry.servlet.SentryServletRequestListener -> javax.servlet.ServletRequestListener not found
io.sentry.servlet.SentryServletRequestListener -> javax.servlet.http.HttpServletRequest not found
为了在 OpenJDK 11.0.11+
上修复此问题,需要在调用 --ignore-missing-deps
时设置 jdeps
。如果完成,则输出再次看起来正确:
java.base
java.logging
java.naming
问题
所以我可以使用 JDK jdeps
使用 11.0.11+
生成与使用 JDK 11.0.10-
相同的输出。话虽如此,此输出用于创建自定义运行时,并在 JDK-8214213
的描述中明确说明:
注意一个
自定义图像是使用 jdeps 输出的模块列表创建的
将 --ignore-missing-deps
选项用于非模块化
应用。此类在自定义映像上运行的应用程序可能
当缺少依赖错误被抑制时,在运行时失败。
根据我的理解,这意味着如果涉及传递依赖,其中依赖的依赖需要任何顶级依赖都不需要的运行时模块,那么这可能导致自定义运行时无法运行应用程序,因为无法解析传递依赖。换句话说,如果我的应用程序需要依赖项 A
,它需要依赖项 B
和模块 C
,但依赖项 B
也需要模块 D
,那么我的应用程序有遇到运行时错误的风险,因为我的自定义运行时没有随模块 D
一起提供。
我现在的问题是这个,因为我无法从文档中得出它:
使用 JDK 11.0.11+
时,如果使用 --ignore-missing-deps
,我只能获得相同的依赖项列表输出。这是否意味着...
- ...
jdeps
能够在11.0.11
之前解决传递依赖关系,但不能再高于上述版本,例如因为依赖分析在jdeps
中的内部执行方式不同? - ...
jdeps
的行为就像默认在--ignore-missing-deps
之前使用11.0.11
,因此如果默认更改,jdeps
现在会抛出一个11.0.11+
上的错误? - ……还有什么事情吗?
得到的依赖列表可能是一样的,只是因为有很多库,所以大多数模块都是以两种方式使用的。但是我想确定,是否
jdeps --list-deps -filter:module --multi-release=11 "..\somePath\sentry-1.7.25.jar (11.0.10)
和
jdeps --list-deps --ignore-missing-deps -filter:module --multi-release=11 "..\somePath\sentry-1.7.25.jar (11.0.11)
行为完全相同,或者在向我们的项目添加新库时使用 --ignore-missing-deps
是否会带来新风险,因为它们可能在某些时候需要一个不属于当前 jdeps
-列表。
请记住,对我来说,这是对 OpenJDK 细节的深入探讨,所以如果我对这些场景的理解有错误的术语或问题,请随时指出并纠正它们。
解决方法
暂无找到可以解决该程序问题的有效方法,小编努力寻找整理中!
如果你已经找到好的解决方法,欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@)