Enthuware

I think that objects wrapped by this class are not thread-safe
If
1 in constructor copy input parameter to the obj
2 in getObject method returns copy of the obj
=> it will be thread-safe

Am I right?

No, that is not correct.
1. Because even if you return a copy of the object in getObject, a reference of this object that was passed to setObject already exists outside this class.
2. You dont know whether the clone is a deep clone or a shallow clone. It depends on how the class of the wrapped object is written.

This class will not even compile, because it has a final field that is not initialized, compile error will be shown, isn't this correct ?

What happened when you actually tried to compile it?

Ha ha yes.
final fields do not need to be initialized with a value at the same time that they are declared; they can be initialized in either an IIB or a constructor.

If the constructor was a method, setObject or something, this class would be thread-unsafe right? since a calling class could insert and get it right after thinking it would get that object while another thread could called the setter in the period between these 2 actions.

To put it differently, would you call a class with only getters and setters thread-unsafe?

Correct, assuming the setter does not use any synchronization mechanism, it would be thread unsafe.