Java Beans Introspector需要桌面模块 [英] Java Beans Introspector requires desktop module

查看:140
本文介绍了Java Beans Introspector需要桌面模块的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I'm investigating using Jigsaw to reduce the footprint of a microservice. One of the last dependencies I had to find was java.beans.Introspector.

当我发现需要引入包含整个模块的java.desktop时,我会感到惊讶各种不相关的东西,如awt,applets,swing等。

Imagine my surprise when I discovered I needed to bring in the whole module java.desktop which contains all sorts of irrelevant stuff like awt, applets, swing etc.

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

This seems crazy to me, surely bean introspection should be a part of the fundamental language and not related to UI functionality. I think the dependency comes from the embedded Tomcat from Spring Boot so it's not something I can modify myself.

问题:模块是你能访问的最好的粒度还是那里另一种修剪脂肪的方法。

The Question: Are modules the finest granularity you can access or is there another way to trim the fat as it were.

推荐答案

依赖存在,因为 BeanInfo SimpleBeanInfo 从AWT包中引用 Icon Image 。此外,API中有一些类不可见,它们引用了桌面类,即为这些桌面类提供的默认属性编辑器和持久性委托实现。

The dependency exists, because BeanInfo and SimpleBeanInfo have references to Icon and Image from the AWT package. Further, there are some classes not visible in the API having references to desktop classes, i.e. the default property editor and persistence delegate implementations shipped for these desktop classes.

自Java模块以来不允许包跨越多个模块,没有办法将功能拆分为AWT依赖模块和非依赖模块(以向后兼容的方式)。动态加载的工件,即实际的bean信息,编辑器和持久性委托,可能已被移动到另一个模块,但不是 BeanInfo 接口及其 SimpleBeanInfo 实现。

Since Java modules do not allow packages spread across multiple modules, there is no way to split the functionality into an AWT dependent and a non-dependent module (in a backward compatible manner). The dynamically loaded artifacts, i.e. actual bean infos, editors and persistence delegates, could have been moved into another module, but not the BeanInfo interface and its SimpleBeanInfo implementation.

在没有创建依赖关系的情况下,没有更精细的粒度和使用bean类的解决方案。 JDK开发人员如何处理由此决定引起的问题,可以很好地说明这一点。由于 java.util.logging.LogManager java.util.jar.Pack200.Packer / Unpacker 支持 java.beans.PropertyChangeListener ,这导致依赖 java.desktop ,如果保持这种方式,这些方法是从标准Ja​​va API中删除的第一种方法,就像第一次在Java 8中被弃用并且已经在Java 9中删除一样快。

There is no finer granularity and no solution to use bean classes without creating that dependency. This is best illustrated by how the JDK developers dealt with the problems caused by this decision. Since java.util.logging.LogManager and java.util.jar.Pack200.Packer/Unpacker had support for java.beans.PropertyChangeListener, which caused a dependency to java.desktop, if kept that way, these methods were the first methods ever removed from the standard Java API, as fast as being deprecated in Java 8 for the first time and already removed in Java 9.

我认为,如果有一种方法可以声明对基本bean类的依赖,例如 PropertyChangeListener 而不会创建对的不需要的依赖项java.desktop ,JDK开发人员没有设置这个先例。

I think, if there was a way to declare a dependency to the fundamental bean classes like PropertyChangeListener without creating the unwanted dependency to java.desktop, the JDK developers didn’t set that precedent.

这篇关于Java Beans Introspector需要桌面模块的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆