OSJ-256, final classes, final interfaces and IdP V4

Rod Widdowson rdw at steadingsoftware.com
Sat Jan 5 09:53:46 EST 2019


As a result of a back-channel discussion I have with Scott last night about Dependency management I got to thinking about our API
classes and Interfaces and people who are not the developer team extending them.

In OSR-256 there is a suggestion that we should make all our context classes final "so we can freely add things in minor releases
(which we've been doing anyway)."

I heartily concur, but I'd like to suggest (provocatively) that we should ship V4.0 with *every* class marked final - the exception
being those classes which we ourselves derive from, i.e. those classes which would break the build if marked final.

The Contexts are the obvious cases but the attribute resolver and indeed filter has a bunch of classes and interfaces which are not
really suitable for "other than us" extension.  Examples are the net.shibboleth.idp.attribute.resolver interfaces:
	AttributeDefinition
	AttributeResolver
	DataConnector  (which has in fact been extended during a minor release)
and the class
	ResolverPluginDependency (again extended during a minor release).

None of these classes are really suitable for extension by anyone but ourselves and AFAICS removing final from a class or interface
can be done at any time without breaking compatibility.

There are other examples - which is where my "add final unless it break the compile" suggestion come from.

What do people think?

R



More information about the dev mailing list