Java Beans Introspector requires desktop module

Question

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.

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.

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.

Adkisson

Answer 1

The dependency exists, because BeanInfo and SimpleBeanInfo have references to Icon and Image from the AWT package. Further, PropertyEditor declares the methods getCustomEditor and paintValue​ creating dependencies to the classes Component, Graphics, and Rectangle. There are also 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.

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 and PropertyEditor interfaces and their SimpleBeanInfo and PropertyEditorSupport implementations.

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.

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.

Vair

The comment "not visible in the API having references to desktop class" is misleading. Please look at APIs such as Beans.instantiate​, BeanInfo.getIcon, SimpleBeanInfo.loadImage and other methods. If there are proposals for splitting the java.beans API in a ways that do not break existing code then please bring those proposals to OpenJDK. – Pard

@AlanBateman well, as said, I remembered a discussion, where the editors and persistence delegates were brought up. The icon support was not mentioned there, and of course, that’s the important missing piece. Now I understand (wouldn’t it be great, if there was a document were API developers documented their design decisions?). I updated the question. – Vair

There is also the method PropertyEditor.paintValue​(Graphics gfx, Rectangle box) that binds to AWT. Well the Beans technology was created with a GUI in mind, as the Visibility inteface suggests: "Under some circumstances a bean may be run on servers where a GUI is not available.". – Loesceke

Indeed today we think a JavaBean as a Serializable object that follows conventions that make it easy to introspect it. But in the beginning the technology was created to support editors that manipulate software components, especially graphical ones. – Loesceke

@Loesceke how could I overlook those methods in PropertyEditor? Added them… • As far as I can remember, the possibility of non-visual components was always considered back then, at least we already had some at that time. However, the Java 1.1 API was tiny, no-one considered the need to split it into independent modules by that time, so package dependencies of that kind were not considered a problem. Especially as classes were loaded lazily anyway. – Vair

Well the design of that classes/interfaces was a bit poor clearly violating the single responsibility principle – Loesceke