I don't often use `final` for classes in code where I control the caller and the user, but for library call I tend to agree with Josh Bloch (Effective Java, Second Edition, Item 17: _Design and document for inheritance or forbid it_)

There are two common problems that `final` classes can have

- You can't mock them. Since `Description` is a value object, and will now have a good builder, then there's no reason to mock `Description` or it's subclasses; you just create a `Description`. If mocking is required, but I want to forbid extension, then I make the constructors private
- You can't subclass them. In this case, subclassing is dangerous, because someone could create a class that extends `ImmutableDescription` that behaves like it is mutable.

In this case, it looks like all of the constructors for `ImmtuableDescription` and its subclasses are package scope or private, so I'm fine removing `final` as long as we are careful about making sure that the only way for library users to build an `ImmutableDescription` is via a builder that ensures deep immutability.