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.

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.