A solution to the final classes problem

[Randahl Fink Isaksen]

Thank you Phil – that is my point exactly! Whether or not an app is allowed to open a file *is not* a question of whether you make FileChooser final. It is a question of whether the app is allowed to do stuff like read from the hard drive. 

A sound design would separate the stuff developers could safely customise into a non-final customisable class, and put the stuff which *really* needs to be final into its own final class. For example, I am sure you agree that it does not matter to the security of JavaFX whether I get to override the way the title of the FileChooser is set. Currently the title is set like this

myFileChooser.setTitle("The title");

I wish to subclass FileChooser so developers who use our framework can create OurFileChooser like this

public class OurFileChooser {
    OurFileChooser(String keyToTitleResource) {
        String title = InternationalizationSystem.getString(keyToTitleResource);
        setTitle(title);
    }
}

where the constructor of OurFileChooser automatically loads the proper internationalized text for the title using the resource key the developer provides, and then sets the title.

We could build this, if the FileChooser class was not final, and you could still put all the things you want to prevent me from overriding in a final class which FileChooser delegates to.

And this is just an example – there would be many other cool things I could do in a subclass to save the application developer a lot of hard work.

I do not disagree with you – maybe some things need to be final. I just think you cast too wide a net, that is all.

Randahl


On Sep 2, 2012, at 6:39 , Phil Race <philip.race at oracle.com> wrote:

> FileChooser probably isn't the best example here, since it implies a level of trust to be able
> to access the file system so as to your point here, sandboxed apps surely can't  "ship any kind of FileChooser"
> They'd have to live within whatever we allowed untrusted apps to do which may be very little
> for a FileChooser.
> 
> -phil.
> 
> 
> On 9/1/12 9:30 PM, Randahl Fink Isaksen wrote:
>> Phil, any JavaFX developer can *already* ship any kind of FileChooser they want to. No matter how you ship your platform, you cannot prevent anyone from creating an app containing their own EvilFileChooser. The fact that you have a final class called FileChooser does not prevent that, as no one is forced to extend your class.
>> 
>> Moreover, I bet that 99% of the JavaFX apps that uses the FileChooser do so from a method in the app that is not declared final. How would you prevent anyone from overriding that app method and bringing up another EvilFileChooser?
>> 
>> I think it is a shame to lower the flexibility of JavaFX just to get a false sense of security.
>> 
>> Randahl
>> 
>> 
>> 
>> On Sep 2, 2012, at 4:58 , Phil Race <philip.race at oracle.com> 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.
>>> 
>>> -phil.
>>> 
>>>> That way, I can extend the FileChooser in our framework and create OurFileChooser which automatically does a lot of useful work for the application developer, such as providing automatic internationalization support, that sets the title in accordance with the user's preferred language.
>>>> 
>>>> The result would be
>>>> 
>>>> OurFileChooser --extends--> FileChooser --knows--> final SecureFileManager
>>>> 
>>>> If you guys keep your classes final, we third party developers end up with a much less desirable design
>>>> 
>>>> OurFileChooser --knows--> FileChooser
>>>> 
>>>> This design requires us to implement every single method of FileChooser in OurFileChooser for the sole purpose of delegating to your class, which is a lot harder to maintain, and a lot more error prone.
>>>> 
>>>> Yours
>>>> 
>>>> Randahl
>>>>  
>>>> 
>>>> On Aug 31, 2012, at 18:15 , Richard Bair <Richard.Bair at oracle.com> wrote:
>>>> 
>>>>>> Richard, I agree that obvious cases like java.lang.String have to be final to avoid security related issues. But how can that be a defence for the final classes found in JavaFX, like Text and WebView?
>>>>>> 
>>>>>> Currently, I can extend PasswordField if I want to create a security breach which sends the user's password off to a remote server in Thailand, but I cannot extend Text to create a banner component which automatically makes the Text fill color flash, or extended WebView to add more innovative features. Where is the sense in that?
>>>>> That is actually not the security problem (because unless the attacker already has elevated privileges, they can't communicate to a different server anyway). No, the security problem with non-final classes has to do with attacks related to hacking finalizers, equals, hash code, and serialization from a sub class.
>>>>> 
>>>>> Really, security is like threading. It isn't impossible, but there are things you can do with respect to your API that make it harder, or easier, to be secure (just as there are things you can do which make it harder, or easier to design APIs that are thread safe).
>>>>> 
>>>>>> Whenever you make a non-value class final you prevent third party framework developers from adding more innovative features. You take the "open" out of open source. It is just wrong.
>>>>> I can see you are passionate about that :-). In some cases I would agree, in others I would disagree. Designing APIs for mass consumption and that are intended to be supported for many, many years is a different ballgame.
>>>>> 
>>>>> Cheers
>>>>> Richard
>