Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#9,435 2 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Quiet
Tech stack
kotlin
Domain
api

Research direction

Start by reviewing the okhttp3.internal package and the issue’s example, okhttp3.internal.Util.kt, to understand which symbols are public and how users may depend on them. The issue asks for a project-wide API stance; done means deciding which symbols should be Kotlin internal and which, if any, should be supported API.

Written by the indexing model from the issue text.

Description

bug

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.

Dominant language
Kotlin
Stars
47.1k
Forks
9.3k
Avg merge
18h 18m
Merged PRs (30d)
15

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lysine-dev/okhttp

All issues in lysine-dev/okhttp

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.