JDK-8294469 : Deprecate for removal ResizeFeaturesBase public constructor
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: openjfx20
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2022-09-27
  • Updated: 2022-12-13
  • Resolved: 2022-12-13
Related Reports
Blocks :  
JDK-8294470 - Remove ResizeFeaturesBase public constructor
Cloners :  
JDK-8294470 - Remove ResizeFeaturesBase public constructor
Relates :  
JDK-8293119 - Additional constrained resize policies for Tree/TableView
Description
Let's make the ResizeFeaturesBase constructor package scope, which would remove it from the public API. There seems to be no good reason for the constructor to be public, since we really don't want to allow arbitrary subclassing.

This suggests that we might want to file a bug to deprecate the constructor for removal in 20 and remove it (i.e., make it package scope) in 21.

This ticket is for deprecating the public constructor.
This comes from work done for alternative column resize policy JDK-8293119.
Comments
As part of our discussion of the CSR for constrained resize policies (see JDK-8294398), we decided to both make FeatureResizeBase abstract, and to leave the public constructor in place. As such we should close both this and the follow-on Enhancement (JDK-8294470) as "Won't fix".
13-12-2022
This class was never intended to be extensible by application. Leaving in a public constructor is an attractive nuisance, although one I very much doubt any application would take advantage of. If we thought otherwise, then we are doing a disservice by breaking compatibility in implementing JDK-8293119. So I don't buy the argument that this is a "significant impediment to the app". As for what problem we are trying to solve, we might avoid a potential repeat of the compatibility problem we face now with this class. I hope we have done due diligence and added the only two methods that were missing to this class, but if not, any future abstract (or "throws UOE from the base class") method added would be an incompatibility. Without a public constructor, this isn't the case. In any case, I see this potential deprecation as secondary to the more important question we are discussing as part of JDK-8293119. Let's finish that discussion first.
13-12-2022
"We can", yes. But if we make it private, the application developers would not be able to write unit tests. So we will be adding a significant impediment to the app developers while gaining almost nothing. What problem are we trying to solve by making this class constructor private?
13-12-2022
We can do whitebox testing without a public constructor, if that's the only reason for keeping it. And an app developer can test it better using TableView or TreeTableView (so I don't see that as a good argument for keeping it). We can discuss whether or not we still want to deprecate it along with deciding whether to make the class abstract. I could see an argument being made either way, but I don't see it being usefully extended. The reason we are even considering making it abstract is that it isn't useful for anything other than as a common superclass for TableView.ResizeFeatures and TreeTableView.ResizeFeatures, which is also a good argument for eventually getting rid of the public constructor.
13-12-2022
[~kcr]: I would recommend against deprecating / removing public constructor. The use case I worry about is ability to create these objects outside of the javafx, for example for testing. A developer of a custom resize policy should be able to create a unit test by instantiating ResizeFeaturesBase objects. What do you think?
13-12-2022