-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change OkHttpClient.routeDatabase to be internal #7017
Conversation
This is the only behavior change in the PR. The rest is converting a test from Java to Kotlin (so it can see this internal member) and getting a TaskRunner instance into the ExchangeFinder, hopefully useful for implementing Happy Eyeballs. Also fix up some formatting problems.
@@ -227,7 +227,8 @@ open class OkHttpClient internal constructor( | |||
@get:JvmName("minWebSocketMessageToCompress") | |||
val minWebSocketMessageToCompress: Long = builder.minWebSocketMessageToCompress | |||
|
|||
val routeDatabase: RouteDatabase = builder.routeDatabase ?: RouteDatabase() | |||
internal val routeDatabase: RouteDatabase = builder.routeDatabase ?: RouteDatabase() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the behavior change. This should never have been non-internal; it was a mistake to have an internal
type in a public API.
@Test public void nullNetworkInterceptor() { | ||
OkHttpClient.Builder builder = new OkHttpClient.Builder(); | ||
try { | ||
builder.addNetworkInterceptor(null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this test (and a couple similar) because Kotlin doesn’t allow us to express it. We’re letting the type system do something Java required us to do manually.
One comment about internal vs package "okhttp3.internal", when I try to understand behaviour of connections, but maybe in the future Routes, especially for Happy Eyeballs, I tend to use some of these internal APIs. No objection, but what visibility would you expose for happy eyeballs? Just the existing connection events in EventListener? |
I think we should make it opt-in initially. That way if we make a correctness or performance regression in some edge cases the user has recourse. Then opt-out later! |
This is the only behavior change in the PR. The rest is converting
a test from Java to Kotlin (so it can see this internal member) and
getting a TaskRunner instance into the ExchangeFinder, hopefully
useful for implementing Happy Eyeballs.
Also fix up some formatting problems.