Summary
Many people imply that 'final' in Java aids security. I don't think I buy that.

If you know me, you know my perspective on testing. I like to have unit tests for code and I try to write them whenever I can. At times, though, it becomes pretty obvious to me that library designers don't share that interest because they seem to do everything that they can to make testing impossible. Their most common approach is to make classes and methods final or sealed.

Why would this be a problem? Well it's not a problem for the classes that use final, but try to unit test a class which uses one of those classes and you'll see what the trouble is. If the test for your class needs to mock out the use of that final class, your back is against the wall. All you can really do is wrap the final class in some non-final adapter. And, if you do that, well, how's security going? If you use your wrapper pervasively it's the vulnerable point now.

No, there's a measure of security when you use final but only if you imagine that your users aren't really writing unit tests for their code.

Isn't it ironic that we may be able to have secure software, but only if we can't be sure that it actually works?

Talk Back!

Have an opinion? Readers have already posted 23 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Michael Feathers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Michael has been active in the XP community for the past five years, balancing his time between working with, training, and coaching various teams around the world. Prior to joining Object Mentor, Michael designed a proprietary programming language and wrote a compiler for it, he also designed a large multi-platform class library and a framework for instrumentation control. When he isn't engaged with a team, he spends most of this time investigating ways of altering design over time in codebases.