Request for Java-friendly support when customizing OkHttp (current implementation in Kotlin causes difficulties)

📌 Background

Currently, to customize the OkHttp client, the recommended approach is to copy the OkHttpClient implementation from openai-java-client-okhttp and modify it.
However, since the implementation is written in Kotlin, this process is difficult for developers working in pure Java projects.

⚠ Problems

1. Language barrier

   • Requires understanding of Kotlin syntax (apply, null safety, extension functions, etc.).
   • Converting the code to Java requires additional work.

2. Build environment overhead

   • Pure Java projects need to add the Kotlin build plugin to use the copied code.
   • This introduces extra build configuration and dependency management burden.

💡 Suggestions

• Option 1: Provide a Java-friendly abstraction layer

  • e.g., an OpenAIOkHttpClientBuilder that allows configuring Timeout, Dispatcher, Interceptors, etc.

• Option 2: Allow direct injection of an OkHttpClient instance via factory methods

  • Example:

    OpenAIClient client = OpenAIClientImpl.builder()
        .apiKey("...")
        .httpClient(customOkHttpClient) // Built via OkHttpClient.Builder
        .build();
    

• Option 3: Provide a Java version of the current Kotlin implementation as a sample

  • So Java developers can copy and modify it without Kotlin dependencies.

✅ Expected benefits

• Java developers can customize OkHttp without learning Kotlin.
• Significantly lowers the barrier compared to the current “copy-and-modify” approach.
• Improves flexibility for adapting to different network environments.

Start by reading the current Kotlin implementation in openai-java-client-okhttp and the OpenAIClientImpl.builder entry point. Determine which Java-friendly customization approach should be supported, then verify that Java projects can configure or inject a custom OkHttp client without Kotlin build dependencies.