BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Opinion: Final should be default, not deprecated

Opinion: Final should be default, not deprecated

Bookmarks
Elliotte Rusty Harold has joined a growing discussion across some blogs and lists about the topic of deprecating the final keyword in Java, saying that final should be 'default' unless explicitly marked otherwise, at least for methods. According to Elliotte (from an earlier post), the lack of finality has created a huge, brittle, dangerously breakable infrastructure in the world of Java class libraries.

Elliotte starts off putting design by contract in context to inheritance, saying that the the subclasses must maintain the class invariants and postconditions of their superclasses.   Subclasses can relax a parent classes preconditions but not over ride them, as that would make it impossible to guarantee the behavior of the sub classes.  Therefore, "it follows that most methods should be fina ...Failing to mark them final risks postcondition, precondition, and class invariant violation."

So Final should not be deprecated, but used all the time, UNTIL Java the language could be modified, in order to:

make preconditions, postconditions, and class invariants language level constructs. Then make them automatically inherited by all subclasses. This would allow subclasses to override methods from the superclass, but would not allow them to change the superclass’s defined behavior. They could only change things the superclass did not explicitly promise.

They’re a lot of other benefits to this scheme as well. First of all it would mean more people would use design by contract, and thus write better code. For those of us who already use design by contract, it would make our code much simpler. But what interests me for the moment is that it would dramatically reduce the need for final. final is really overkill for 90% of the uses to which it’s put.

Elliotte concludes his entry criticizing the over-use of Interfaces:
They’re a lot of high-powered theorists who just love interfaces and abstract factories; and it’s not a coincidence that these are the same people who hate final. They’re wrong about this too, and for the same reason. Java interfaces have no ability to enforce preconditions, postconditions, and invariants. This means they’re appropriate only when a type really doesn’t have any of those, which is rare.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Final is valuable

    by Rod Johnson,

  • Extension mechanism

    by Rod Johnson,

    • Re: Extension mechanism

      by Corby Page,

    • Re: Extension mechanism

      by Michael Hunger,

      • Final is valuable

        by Rod Johnson,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        I agree that the final keyword is a powerful mechanism for maintaining class invariants, and is under-used in many codebases.

      • Extension mechanism

        by Rod Johnson,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        Hand-in-hand with that is the fact that (in my experience, anyway) subclassing and overriding methods is not the right way to extend functionality in most cases. Composition is usually better than inheritance, and patterns such as the Strategy pattern usually offer much better extensibility without the need to risk class invariants.

      • Re: Extension mechanism

        by Corby Page,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        Hmmm... wanted to make a point here, but I can't find a code formatter that makes Java look legible in the message text.

      • Re: Extension mechanism

        by Michael Hunger,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        I don't agree. When overusing the final keyword you force developers who use your codebase to reinvent the wheel or copy your classes to slightly extend them.
        When used with delegation/composition the same fact applies to the delegate used. Mostly it is a implementing class of an interface or a subclass of an abstract or default implementation. When only allowing the methods you think of being worth to be overridden you restrict the possibilities.
        Just today I had to copy the code of NameMatchTransactionAttributeSource as there were no protected methods to be overridden that allow the modification of the matching algorithm (i.e. the access of the map set as property).
        I fully agree when using the final keyword on method parameters, local and global variables that should be fixed and reduce the possibility of coding errors. (Trade semantic errors for compiler errors - see Hardcore Java by Robert Simmons).

        Michael

      • Is it testable?

        by leonardo susatyo,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        The point that the author missed was the fact some of the problems of making classes/methods finals is they tend to be very hard to test.

        Obviously, I agree with the author's points of invariants, etc. But the way I usually enforce invariants are through unit testings. And nothing makes me happier than to have a well designed class resulting from unit testings. TDD anyone?

      • Re: Final is valuable

        by Lars Stitz,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        I agree with you, but I think that both proposals -- deprecating the final keyword, or making it a default setting -- are just trying to cover up symptoms, instead of solving the real problem.

        The real problem as I perceive it is education. Many Java developers simply don't know when to use the keywords final, volatile or even synchronized and transient. Hell, I even keep seeing completely abstract classes where an interface would have done the job nicely.

        The final keyword is definitely a good thing in the Java language. But if a programmer is unable to master that features, only a fool would blame the feature...

        Just my 2 cents, Lars

      • Re: Extension mechanism

        by Lars Stitz,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        I guess nobody is seriously questioning that the overuse of anything is dangerous. Same can be said for food, for instance. Or for the private keyword, for that matter -- as I always have to acknowledge grudgingly when programming Swing.

        The funny thing, though, is that you never notice the "overuse" of private or final in your own software, but only in third party frameworks... ;-)

        Cheers, Lars

      • Re: Extension mechanism

        by Marc Logemann,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        final is the most undervalued keyword in java. I can only fully agree to Elliot here. When certain people say it should be deprecated, i wonder how they develop programs at all.

        Not using final means taking the risk of inproper API usage, resulting in various problems when using APIs in general.

        Marc Logemann

      • Re: Extension mechanism

        by Sam Corder,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        I've always believed that the best written software is used (successfully) for purposes that the author did not intend. For instance the original browser and html were not intended for e-commerce. I think the same should hold true for libraries. I think using final by default makes this hard unless you have been able to predict every possible extension point and use. People here seem to worry about someone creating a subclass that breaks some contract and makes the code behave erratically. That is that coders problem not the original author. They need to write correct code and it isn't my job to make sure that they do it.

      • Re: Final is valuable

        by Rod Johnson,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        Lars

        I agree with you, but I think that both proposals -- deprecating the final keyword, or making it a default setting -- are just trying to cover up symptoms, instead of solving the real problem.

        Both proposals are quite extreme. The language presently offers a good tool that developers can choose to use.

        The real problem as I perceive it is education.

        Exactly. The problem is not the language, it's lack of knowledge of some very important features.

        Rgds
        Rod

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT