Java Beans Introspector 需要桌面模块答案

【问题标题】：Java Beans Introspector requires desktop moduleJava Beans Introspector 需要桌面模块
【发布时间】：2018-09-21 21:07:12
【问题描述】：

我正在研究使用 Jigsaw 来减少微服务的占用空间。我必须找到的最后一个依赖项是 java.beans.Introspector。

想象一下，当我发现我需要引入整个模块 java.desktop，其中包含各种不相关的东西，如 awt、applet、swing 等时，我会感到惊讶。

这对我来说似乎很疯狂，当然 bean 自省应该是基础语言的一部分，并且与 UI 功能无关。我认为依赖来自 Spring Boot 中的嵌入式 Tomcat，所以我不能自己修改它。

问题：模块是您可以访问的最精细的粒度，还是有另一种方法可以减少脂肪。

【问题讨论】：

标签： java java-9 java-platform-module-system java-module

【解决方案1】：

存在依赖项，因为 BeanInfo 和 SimpleBeanInfo 引用了 AWT 包中的 Icon 和 Image。此外，PropertyEditor 声明了方法 getCustomEditor 和 paintValue 创建对类 Component、Graphics 和 Rectangle 的依赖关系。还有一些在 API 中不可见的类引用了桌面类，即为这些桌面类提供的默认属性编辑器和持久性委托实现。

由于 Java 模块不允许包分布在多个模块中，因此无法将功能拆分为依赖于 AWT 的模块和不依赖于 AWT 的模块（以向后兼容的方式）。动态加载的工件，即实际的 bean 信息、编辑器和持久性委托，可以移动到另一个模块，但不能移动到 BeanInfo 和 PropertyEditor 接口及其 SimpleBeanInfo 和 PropertyEditorSupport 实现。

没有更精细的粒度，也没有在不创建依赖项的情况下使用 bean 类的解决方案。 JDK 开发人员如何处理由该决定引起的问题可以很好地说明这一点。由于java.util.logging.LogManager 和java.util.jar.Pack200.Packer/Unpacker 支持java.beans.PropertyChangeListener，这导致了对java.desktop 的依赖，如果保持这种方式，这些方法是有史以来第一个从标准Java API 中删除的方法，速度与首次在 Java 8 中弃用，并已在 Java 9 中删除。

我认为，如果有一种方法可以声明对基本 bean 类（如 PropertyChangeListener）的依赖，而不会创建对 java.desktop 的不需要的依赖，那么 JDK 开发人员并没有开创这样的先例。

【讨论】：

注释“在引用桌面类的 API 中不可见”具有误导性。请看 Beans.instantiate、BeanInfo.getIcon、SimpleBeanInfo.loadImage 等 API 等方法。如果有建议以不破坏现有代码的方式拆分 java.beans API，那么请将这些建议提交给 OpenJDK。
@AlanBateman 好吧，如前所述，我记得有一次讨论，其中提出了编辑和持久性代表。那里没有提到图标支持，当然，这是重要的缺失部分。现在我明白了（如果有一个文档，API 开发人员记录了他们的设计决策，那不是很好吗？）。我更新了问题。
还有绑定AWT的方法PropertyEditor.paintValue(Graphics gfx, Rectangle box)。好吧，Beans 技术是在考虑 GUI 的情况下创建的，正如 Visibility 界面所暗示的那样：“在某些情况下，bean 可能会在 GUI 不可用的服务器上运行。”。
事实上，今天我们认为 JavaBean 是一个可序列化的对象，它遵循易于自省的约定。但一开始，这项技术的创建是为了支持操作软件组件的编辑器，尤其是图形组件。
@user1708042 我怎么能忽略PropertyEditor 中的那些方法？添加它们... • 据我所记得，非视觉组件的可能性在当时一直被考虑在内，至少我们当时已经有了一些。然而，Java 1.1 API 很小，当时没有人考虑需要将其拆分为独立的模块，因此这种包依赖关系不被认为是问题。尤其是因为无论如何都是懒惰地加载类。