new restrictions on non-SDK interfaces break the library starting from API 29 about openjdk-kerberos HOT 3 OPEN

I'm happy to see you using this library - can you elaborate on the context you use it for?
Regarding work-arounds:

• You can build the app such that it targets SDK level 28.
• You can migrate the classes from Sun's OpenJDK into the project.

As you can probably tell, this library contains a subset of the Kerberos implementation from OpenJDK, with some namespaces changed to not conflict with existing code in the JDK provided with Android.

I would suggest importing classes which are no longer public, e.g. sun.misc.HexDumpEncoder into this library - I'm happy to take patches.

from openjdk-kerberos.

I'm thankful for your prompt reply.

Can you elaborate on the context you use it for?

I'm using it in a simple Android Kerberos client for our company SSO solution. It's much like your Kerberos Authenticator sample adapted for our specific needs and requirements.

You can build the app such that it targets SDK level 28.

Unfortunately, that doesn't help. Part of the classes referenced in the library is listed in the "blacklist" of the API 29, which are "non-SDK interfaces that you cannot use regardless of your app's target API level."—I'm quoting from the official guide.

You can migrate the classes from Sun's OpenJDK into the project.

It should be possible this way. Yet, surprisingly, the NoSuchMethodError exception thrown in the stack trace provided earlier is about a class you already provided in your package: sun/security/util/BitArray. It seems like we had a class conflict here with another version from the SDK, and the resolving strategy is favoring the SDK version.

I'm thinking of relocating the provided subset to a different namespaces to avoid the conflict, and migrate (then relocate) from Sun's OpenJDK those classes that are listed in the blacklist and the greylist and not provided in your subset; what do you think?

from openjdk-kerberos.

I'm thankful for your prompt reply.

Can you elaborate on the context you use it for?

I'm using it in a simple Android Kerberos client for our company SSO solution. It's much like your Kerberos Authenticator sample adapted for our specific needs and requirements.
Great! I'd like to hear more if you can share. I can contact you privately as I'm keen to learn more about environments where it's used, so I can justify spending more work on this.
It should be possible this way. Yet, surprisingly, the NoSuchMethodError exception thrown in the stack trace provided earlier is about a class you already provided in your package: sun/security/util/BitArray. It seems like we had a class conflict here with another version from the SDK, and the resolving strategy is favoring the SDK version.

I'm thinking of relocating the provided subset to a different namespaces to avoid the conflict, and migrate (then relocate) from Sun's OpenJDK those classes that are listed in the blacklist and the greylist and not provided in your subset; what do you think?

Yes, I think that's the only viable course of action.
I agree it's not the prettiest solution and a bit of dredge work, copying class by class and renaming all references in the code (a good IDE will make it much simpler).
But that is the approach I had to take, after consulting with the Android Runtime team, where they made it clear these classes will not be included in Android due to the low use.

from openjdk-kerberos.