Some deeper look into the actual implementation will help an attacker understand the data structure of a memory dump, and from what I found in EncryptorImpl there has been put no effort into obfuscating the key storage mechanism to prolong the time needed for reverse-engineering the secret. So no, this is not an effective measure against exposure of memory.
Let me provide a better usage scenario for this class:
As the key variable is private, at least it's very unlikely a developer would find his way around responding with the key by accident to an attacker (e.g. due to a bug in the control flow of a web service request handler), so there is some use for this class in ensuring the code can only help decrypting by actually decrypting in the background instead of handing out a key. After the program is stopped / taken offline, an attacker won't be able to decrypt secrets anymore, and all decryption that happened until then (when the attacker was using the program as a kind of oracle) had a chance to be logged, which can be relevant in a post-mortem analysis to figure out what data has been compromised.