OkHttp 4.x okhttp3.internal.Util class loading issues when using AppCDS

Hi,

We’ve recently upgraded to OkHttp 4.x (from 3.x) and saw that Java applications that use AppCDS archives, where the okhttp3.internal.Util class is included, fail to start. The error is:

java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    okhttp3/internal/Util
  Reason:
    Type '[Ljava/lang/Object;' is not assignable to 'okhttp3/internal/Util'

	at okhttp3.OkHttpClient.<clinit>(OkHttpClient.kt:1073)

Looking at the classes loaded, it looks like all of them are loaded from the shared objects file

[0.215s][info][class,load] okhttp3.internal.Util source: shared objects file
[0.284s][info][class,load] okhttp3.Call$Factory source: shared objects file
[0.284s][info][class,load] okhttp3.WebSocket$Factory source: shared objects file
[0.284s][info][class,load] okhttp3.OkHttpClient source: shared objects file
[0.285s][info][class,load] okhttp3.OkHttpClient$Companion source: shared objects file
[0.287s][info][class,load] okhttp3.Protocol source: shared objects file
[0.287s][info][class,load] okhttp3.Protocol$Companion source: shared objects file

Steps to reproduce

I’ve managed to isolate this to a very simple Docker image contained in the attachment okhttp_appcds.zip. To replicate, run:

docker build -t okhttp_appcds . && docker run --rm okhttp_appcds

I’ll also include the Java code, Gradle build and the Dockerfile for clarity:

import okhttp3.OkHttpClient;
import okhttp3.Request;
import okhttp3.Response;

public class TestOkHttpAppCDS {

    public static void main(String[] args) throws Exception {
        OkHttpClient client = new OkHttpClient();

        Request request = new Request.Builder().url("http://example.com").build();

        try (Response response = client.newCall(request).execute()) {
            System.out.printf("RESPONSE: \n%s\n", response.body().string());
        }
        
        System.exit(0);
    }
}

plugins {
    id 'java'
}

compileJava {
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
}

jar {
    manifest {
        attributes 'Main-Class': 'TestOkHttpAppCDS'
    }

    from {
        configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
    }
}

repositories {
    mavenCentral()
}

dependencies {
    compile "com.squareup.okhttp3:okhttp:4.8.1"
}

FROM gradle:jdk11

COPY src src
COPY build.gradle .

RUN gradle build

RUN java -XX:DumpLoadedClassList=classes.lst -jar build/libs/gradle.jar

# Uncomment this to remove oktthp from the CDS archive
# RUN sh -c 'cat classes.lst | grep -v ^okhttp3 > classes.lst' 

RUN java -Xshare:dump -XX:SharedClassListFile=classes.lst -XX:SharedArchiveFile=app-cds.jsa -jar build/libs/gradle.jar

CMD java -XX:+UseAppCDS -Xshare:on -XX:SharedArchiveFile=app-cds.jsa -Xlog:class+load -jar build/libs/gradle.jar

[danielgblanco]

Hi @norbertas-gaulia, we ended up filtering our oktthp3 classes out of the CDS archive as mentioned in the Dockerfile above (uncommenting the bits that need uncommenting).

[iklam]

A bug has been filed for the JDK: https://bugs.openjdk.java.net/browse/JDK-8286277