Make okhttp3.internal into `internal` or turn into API

[vkasprov]

Could you clarify the stance on using code from the okhttp3.internal package?

Is this code truly internal (as the package name suggests) in the sense that...

• It does NOT belong to the API
• It CAN be changed without notice between releases
• OkHttp users should NOT directly reference anything from okhttp3.internal

If the above is true and okhttp3.internal is truly internal, could you please mark all of it with Kotlin internal?

The problem is that currently a lot of okhttp3.internal code is public and OkHttp users CAN reference it, which can then break on update. For example, utilities from the okhttp3.internal.Util.kt disappeared on update from OkHttp 4 to 5. This is especially a problem in big codebases with many engineers.

If there is some okhttp3.internal that needs to be accessed by OkHttp users, it might be a signal that it has to be a proper API instead.

[yschimke]

Yeah, I think we agree this was a mistake.

But since you are dealing with source code compatibility, it's rather easier for you to update.

If we make the change now, we break any library that annoyingly used these imports.

[JakeWharton]

We've broken these in the past, and I'm happy to do it more.

Lots of these were public despite the package since they're used across module boundaries and friends modules are badly broken. We probably have to wait for shared internals to do it right. Until then, the ones which cannot be made internal can be put behind an @OptIn.