A solution to the final classes problem
John Hendrikx
hjohn at xs4all.nl
Sun Sep 2 00:40:35 PDT 2012
On 2/09/2012 04:58, Phil Race wrote:
> On 9/1/12 11:20 AM, Randahl Fink Isaksen wrote:
>> Richard, I think we could all benefit from an improved design of the
>> final classes, which would both allow critical parts to be final
>> (like you prefer), while allowing non-critical parts to be overridden
>> (like many on this list prefer).
>>
>> Take FileChooser for instance. I would like to subclass it to add
>> some of my own framework features, but I can't because it is final.
>> After reading the security article you linked to, I can see why there
>> could be sound reasons for declaring it final if, say, the class
>> contains security checks in some methods.
>>
>> I think the main problem is, that both the UI stuff (which I want to
>> override and improve) and the security related stuff (which I do not
>> wish to harm in any way) is rolled into one big class. I believe an
>> improved design would be to implement the FileChooser as a pure UI
>> component that delegates security-sensitive work to a separate class,
>> along the lines of
>>
>> nonfinal FileChooser ----> final SecureFileManager
>
> Really? Implicitly suggesting there's a "non-secure" FileChooser - and
> what's more
> you want to use it ? I'd not buy your app ;-) OK yes, you can promise
> to make it
> secure and what's more you're trustworthy etc, etc. But also we'd
> really not be able to
> ship the platform like that. How many developers would search for "F"
> for FileChooser
> and never spot the one they are supposed to use under "S". Yes, OK
> there's probably
> some clever way you could the right one more obvoius.
> However at the end of the day we can't accommodate everyone's wishes.
> A wants X. B want Y. X and Y are incompatible. Please make A and B happy
> if possible, but if you can't do the best you can .. and above all be
> secure.
If his app does not run in the browser, what's the difference?
Also, what's stopping us from making our own FileChooser, apart from
some time investment?
More information about the openjfx-dev
mailing list