some changes are binary incompatible, they are syntactically
transparent.
Yes, that's the big problem. Binary compatibility is very important. The
value proposition of making the types a bit more clear doesn't justify
breaking binary compatibility.
-- Kevin
On 7/27/2021 6:09 PM, Michael Strauß wrote:
I should point out that the rest of the JavaFX framework did not
require a single code change as a result of the API changes. So while
some changes are binary incompatible, they are syntactically
transparent.
Am Mi., 28. Juli 2021 um 01:39 Uhr schrieb Kevin Rushforth
<kevin.rushfo...@oracle.com>:
This will take a while to work through, and we will need to get general
consensus on the API changes.
I doubt I can support incompatible breaking changes in this area, given
how fundamental property and bindings are to JavaFX. I'll take a look,
but it is likely that the incompatible API changes part of your proposed
change will not be accepted.
The changes enforcing correct usage should be a lot less controversial
and easier to get through.
-- Kevin
On 7/27/2021 4:23 PM, Michael Strauß wrote:
I propose a set of changes to the JavaFX property system that I've
outlined in this PR:
https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/590__;!!ACWV5N9M2RV99hQ!egor-rENORC_wn09Va7FeNBmsgCGsCm3yzccC3yvO_x-wuuyMXrzpE_OplPNe2pJWeue$
The changes fall into two categories: enforcement of correct usage
(there are several cases listed in the PR), and deprecating untyped
APIs (for removal in a future version) so as to make the intent of the
API more clear to developers.
Even though there are breaking changes, the impact on application code
should be minimal. I'd welcome any comments on this proposal.
