1

What's up with all these final classes? Want to extend User? Have the Userbuilder return an instance of the CustomUser? No go. UserBuilder is final and returns a minimalistic UserDetails instance. All that functionality goes to waste or becomes a copy/paste exercise.

Then, @Steve Riesenberg wrote a nice convenience Mapper(OAuth2AuthorizationServerPropertiesMapper) - also final/package private.

Sure - composition, but that is one really annoying solution and what do you do with cases like the OAuth2AuthorizationServerPropertiesMapper where the constructor is package private?

Anyone want to shed some light on this trend?

How do you all get around this? Do i need to stick my head deeper into the Java manual?

Buks van der Lingen
  • 31
  • 5
  • I don't think it's a trend. With final, you want to prevent the class from being extended by changing functionality. This can affect other functionality and stability. Do the classes you need provide interfaces? Then implement the interface and develop the functionality yourself. I have published a package on Maven Central. Most of the classes are final because I do not want them to be extended. Because I am still working on them or even removing, renaming or moving classes. – Hans FooBar Jun 17 '23 at 15:48
  • @HansFooBar, sure, all valid reasons. Just like all Spring's reasons are valid. Doesn't change the fact that it makes it harder to get the customizations/extentions implemented. – Buks van der Lingen Jun 22 '23 at 15:00

1 Answers1

0

Your question references classes in both Spring Boot and Spring Security, as well as alluding to the Spring Authorization Server project. The fact that all three (3) projects use these techniques indicates that it is intentional.

Regarding OAuth2AuthorizationServerPropertiesMapper, the Spring Boot team made this class package-private so that it cannot currently be accessed by users. That allows the flexibility to move it (which it likely would before being made public) and/or change it completely. Hiding classes is a common technique for allowing the framework to reserve the right to change implementation details without breaking the API contract.

The same is true of final classes, though the intention there is to encourage delegation instead of inheritance. Full customization is possible by implementing interfaces that the final classes implement, and delegation is almost always possible when doing so.

Steve Riesenberg
  • 4,271
  • 1
  • 4
  • 26
  • Thanks @Steve Riesenberg, so i gathered. Delegation/Composition = schlep, and i understand you would like to reserve the right..... for just about anything in the framework classes but, like always, would a migration comment not suffice? – Buks van der Lingen Jun 22 '23 at 14:55