If I recall correctly, those methods had dependencies that crossed the module boundaries in unpleasant ways, so that keeping them would mess up the module boundaries.
Parameter class in question: http://download.java.net/java/jdk9/docs/api/java/beans/Prope...
> A "PropertyChange" event gets fired whenever a bean changes a "bound" property. You can register a PropertyChangeListener with a source bean so as to be notified of any bound property updates.
I believe the idea of a "bound" property is a Swing UI concept. That is, it implements a binding from the bean to a UI element. If you look at the implementing class list, it's all Swing UI components that implement it.
[0] http://download.java.net/java/jdk9/docs/api/java/beans/Prope...
Well the java.beans package and Swing UI are in the same module. Why? Because java.beans depends on AWT. Why? Because of interfaces like this https://docs.oracle.com/javase/8/docs/api/java/beans/BeanInf... Could AWT und Swing still be split into different modules? Maybe. Does that mean that almost every Java application will have to deploy two UI toolkits, PLaFs and sound even if it's just a web service? Yes because almost every Java application at least indirectly depends on java.beans. Does Oracle or Java 9 / Jigsaw marketing care? No.
Mostly simplified calling of getters and setters, i.e. emulation of object properties.
> Why do you say almost every Java application depends on it?
- JAXB (XML binding) and Activation depend on it, so if you have direct or indirect dependency on JAXB or Activation you need java.beans.
- Spring depends on java.beans