A solution to the final classes problem

[Mark Fortner]

It would also be useful if FileChooser could be used with nio2 classes.
 This would make it possible to support new file systems.

Cheers,

Mark




On Sat, Sep 1, 2012 at 11:20 AM, Randahl Fink Isaksen <randahl at rockit.dk>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
>
> 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
>
>