Can we avoid having this?

With a path you can explicitly initialize a credential.

We don't want to add public method here unless it has a wide use case.

@TimurSadykov I modified the PR to expose the path only, using DefaultCredentialProvider.getWellKnownCredentialsFile().getAbsolutePath(). Our use case requires accessing a public method of this library

@TimurSadykov If not a public method in GoogleCredentials, where would it make most sense to expose the path method?

IIRC, we agreed on exposing the logic that returns the path, not the actual credential. This logic has some ADC-specific stuff, like printing warnings about user credentials, that you don't need.

Seems like the getWellKnownCredentialsFile is what you need, or new method that encapsulates just the Path part of the File creation.

I exposed a method to wrap getWellKnownCredentialsFile's path.

Yep, that is better

You probably want to revert this change (as no longer needed) or cover it with tests... either works

This could backfire because here we rely on the fact that default credentials provider is static and always the same. This could change and if we decide to change it - this method will make things more complicated.

How about you move the logic of the getWellKnownCredentialsPath into a new public Utils class, like GoogleAuthUtils. (all the existing utils classes are internal and therefore private) IIUC the path logic is actually static. We already have some other public static methods that could be moved to the new Utils class as well.

I created a GoogleAuthUtils with a getPath method that would use the default provider instance to resolve the path. It also has internal methods to use a test provider

You probably want to revert this change (as no longer needed) or cover it with tests... either works