The particular combination of things is, some library includes some method signatures that accept and return a specific struct (not a specific interface). Then, also, there is no exported way to make one of that struct, or to set its fields. Now you cannot write a library that wraps the original library and exposes the same API (unless you use unsafe and reflection).
In the OO languages I have encountered there seems to be a stronger convention toward using interfaces instead of struct or class types in this sort of situation, but people are certainly free in Java to use a final class type as the type of their parameters and return values if they want to make their library less composable.
No, but it's a more prevalent problem in the actual standard library of Go. The Java standard library does not regularly use final classes with private constructors and setters as the parameter and return types in its APIs (which would also prevent people from implementing those APIs). It uses interfaces.
