> > Perhaps this is the right time to move this forward?
I don't see why not. Except for changing the `requires` declaration in the module-info and mentioning it in the docs, is there anything else that needs to be changed? On Sat, Nov 18, 2023 at 7:48 PM Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > We would need to validate the assertion that an app can't doing anything > useful without the app itself importing and using java.beans from the > java.desktop module. > > At a minimum this would need a CSR specifying this additional requirement > that the app must depend on java.desktop in order to use the JavaFX beans > property adapter classes. > > If others think this is useful, we could consider this for JavaFX 23. > > -- Kevin > > On 11/18/2023 6:16 AM, Kevin Rushforth wrote: > > Perhaps the module can be declared 'requires static'. > > > That was my thinking as well, which is captured in > https://bugs.openjdk.org/browse/JDK-8240844 > > Perhaps this is the right time to move this forward? > > -- Kevin > > > On 11/17/2023 4:06 PM, Nir Lisker wrote: > > Hi, > > A previous discussion mentioned the removal of AWT dependencies. One of > the points that Kevin brought up was > > Refactor Java Beans implementation in javafx.base such that java.desktop >> is optional > > > John and I looked at this some time ago when we discussed the usage of the > javafx base module outside of JavaFX, as its observables/binding > capabilities are suitable for non-GUI applications, which currently have to > pull in GUI modules as dependencies. > > The dependency is used in the property.adapter packages that bridge > javafx.base properties with Java Beans. I think that these classes are > seldom used. > > What could be a way to deal with that dependency? Perhaps the module can > be declared 'requires static'. Or extract the adapter packages into a > different "interop" module (javafx.javabeans) like javafx.swing? > > - Nir > > > >
