It's not particularly unsafe, so unless there's anything critical that you'd want to hide in this class or if the class is part of a critical path (like a secure handshake or "hidden" feature), I wouldn't consider this an issue at all.
Furthermore, we're talking about Java here. So if we're talking about a client-side app running Java on the client, they can always modify their JRE to use add their own debugging routines and/or use a custom classloader and access your classes pretty much any way they want to. Making it harder for them (by way of hiding stuff deeper, or even obfuscating code) is always a possibility, but it usually isn't cost-effective when you consider the time and effort needed to achieve this against the loss caused by statistically improbable malicious users.
If we're talking about a server-side piece of software that may output logs to clients (say, to the user's browser), then it probably isn't too big a deal, but it's already more straightforward to fix: configure your container accordingly, and use a logging framework or multiplexer to output to appropriate files on the server for debugging purposes instead. This way you retain useful records for debugging but don't compromise potentially useful information.
But in general, this probably wouldn't be a problem. it's more what you put in the debug message that could be an issue, as we often tend as developers to output things we work on (you don't want to leave these debug outputs for usernames, passwords, salts and security tokens in clear view).