Add Module Support for OkHttp to Improve Compatibility with jlink and Java 9+ Modules

[boheastill]

Title: Add Module Support for OkHttp to Improve Compatibility with jlink and Java 9+ Modules

Description:

I am currently working on a project using OkHttp (version 4.x / 5.0.0-alpha.14) and encountered an issue while trying to create a modular application in a Java 9+ environment using jlink. The problem stems from the fact that OkHttp does not declare its own module via a module-info.java file, which leads to compatibility issues with the Java Platform Module System (JPMS).

The absence of module declarations in OkHttp causes errors during jlink modular application creation, as OkHttp internally uses modules (such as okio), but it does not provide explicit module definitions, resulting in runtime conflicts and build failures.

Suggested Solution:

I recommend adding official module support to OkHttp as follows:

1. Add module-info.java:
   Include a module-info.java file in the OkHttp repository, declaring the necessary modules. For example:

module okhttp {
    requires java.net.http;  // if OkHttp uses Java's HTTP-related API
    requires okio;           // OkHttp depends on Okio
    exports okhttp3;         // export the relevant packages (adjust based on OkHttp's internal structure)
}

2. Ensure Compatibility with JPMS:
   Ensure that OkHttp works seamlessly with the Java Platform Module System (JPMS) and can function correctly in modular applications, especially when using the jlink build tool.

3. Provide a Version with Module Support:
   If full module support cannot be achieved immediately, would it be possible to provide a clear roadmap or plan to help users understand the progress on module support and avoid issues when migrating to modular Java applications?

Background:

Currently, OkHttp does not declare any modules. While it works fine with JDK 8 and earlier versions, the lack of module support becomes problematic in Java 9+ environments, particularly when using jlink for creating custom Java runtimes. This issue is especially prominent because jlink requires all dependencies to have clear module declarations.

Expected Outcome:

By adding module support for OkHttp, developers will be able to:

• Avoid issues when building custom runtimes using jlink.
• Integrate OkHttp more easily into modular Java applications, improving compatibility with JDK 9+.
• Prevent runtime conflicts and improve overall performance for modular applications using OkHttp.

---

Thanks: Thank you for considering this request. I believe that adding module support for OkHttp will greatly improve its usability in modern modular Java applications.

---

This version is ready for submission. Let me know if you’d like to make any changes or need further adjustments!

[yschimke]

OkHttp added Automatic-Module-Name entries quite a while ago. And hopefully the overlapping modules are now split out.

https://github.com/square/okhttp/pull/3743/files

If I understand correctly, this is a limitation of jlink with such dependencies?

I think we previously pushed back on full support as it was expected to be quite disruptive for both development and builds.

[swankjesse]

Is it possible to support jlink and JDK 8+ simultaneously?

[JakeWharton]

Yeah you can put the module-info.class into META-INF/versions/9/ so that it only applies on JDK 9+ where modules (and jlink) are a thing.

[cowwoc]

Hi @swankjesse

Long time no speak. I hope you're doing well :)

Any chance of getting module-info.java added in time for 5.0.0?

I can help answer any questions you might have regarding supporting both Java 8 and Java9+ simultaneously.

And while we're on the topic, are there any plans to move off JDK 8 in the foreseeable future? Thanks.

[boheastill]

OkHttp added Automatic-Module-Name entries quite a while ago. And hopefully the overlapping modules are now split out.

https://github.com/square/okhttp/pull/3743/files

If I understand correctly, this is a limitation of jlink with such dependencies?

I think we previously pushed back on full support as it was expected to be quite disruptive for both development and builds.

[cowwoc]

@boheastill I don't understand why you closed this issue. jlink needs module-info.java. Automatic Modules won't cut it.

I think we previously pushed back on full support as it was expected to be quite disruptive for both development and builds.

Please elaborate. If you already worked out the split package problems, all that remains is adding module-info.java. If Java8 support is an issue, build a MultiRelease JAR...

[sbordet]

I would also like to point out that it is not just a jlink issue.

The lack of a proper module-info.java is a problem for all those libraries (for example, CometD) that use OkHttp as a dependency.

CometD will get a warning because in its module-info.java, module okhttp3 is an automatic module.

Any application that depends on CometD would have to explicitly fiddle manually with the OkHttp dependencies (e.g. to kotlin.stdlib) in its module-info.java because the lack of module-info.java in OkHttp would not allow to see dependencies transitively from the JPMS point of view (they are resolved from the Maven point of view).

Lastly, there are requirements for certain types of applications to depend on "strong" JPMS libraries (i.e. every dependency in the recursive dependency graph must have a module-info.java) for security reasons: JPMS won't allow deep reflection, or use of classes that are not exported, etc. -- all features provided by JPMS.

I would kindly ask to reconsider this issue, as it is trivial to implement (the module-info.java would be like 5 lines), and if Java 8 support is still a thing, it can be put into META-INF/versions/9/ like already suggested.

Thanks!

[yschimke]

Since we are post 5.0 I'll try to land this CL

#8767

[yschimke]

I've added a github CI test that runs a small test Main method with a jlink JRE in #8767

Is this an appropriate test that this stuff works?