Hi Marc,
> Is there any good reason not to remove the “final” modifier from the
class definition?
Providing extensibility is not as simple as "removing the final
modifier". This would be an API change that needs to be motivated and
discussed just like any other API change. That discussion needs to
include how this would benefit applications (not just yours), and also
discuss how the extensibility should be added. All currently public
methods need to be examined to see which ones would be made extensible,
and which should be left as final (since all methods in a final class
are implicitly final). The class docs and the docs for each non-final
method will need to explain how it should be overridden and whether
there any considerations for doing so.
If a good case can be made for making this class extensible, then we can
discuss the proposed changes on this list. Please see the New features /
API additions sections of the CONTRIBUTING guidelines [1] for what needs
to happen.
> We would like to have this change ASAP.
The earliest this change could show up would be in JavaFX 21, and that
would only happen if someone was sufficiently motivated enough to do the
work needed for the change, and if there is general agreement.
-- Kevin
[1]
https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md#new-features--api-additions
On 3/8/2023 3:30 AM, Toni, Marc wrote:
Hi All,
There is an open Enhancement issue
(https://bugs.openjdk.org/browse/JDK-8090467), back from 2011, to
allow extending from the NumberAxis class.
We (at Vector Germany) want to extend from NumberAxis to overwrite the
implementations of “calculateTickValues” and “calculateMinorTickMarks”
for better tick marks depending on the tick unit.
For testing purposes, we copied the implementation of NumberAxis and
refactored the two methods. But due to licensing issues, we must not
use this approach.
Is there any good reason not to remove the “final” modifier from the
class definition? We would like to have this change ASAP.
Best regards,
Marc Toni
