Most of it is the documentation, but there is also the need to find and
document any cases that could fail. My expectation is that those are
uninteresting corner cases.
The documentation for the property adapter classes indicates that its
use is for inter-operating between JavaFX properties and JavaBeans.
We do have one system test that creates a modular test app that mocks up
a trivial use of a POJO class without the test app itself using
java.beans. It isn't actually testing beans, but rather testing the
ability of the property adapter classes to access the user-provided
class at all when the app is in a module. Adding a dependency on
java.desktop would be a trivial thing to do in that test's module-info.java.
-- Kevin
On 11/18/2023 6:42 PM, Nir Lisker wrote:
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
