`gdk-parent:4.10.17` selects malformed Netty `4.2.16.Final-oracle-00001` JARs, causing `InvalidJarIndexError` on JDK 17

[jasonlyle88]

Component

GDK dependency packaging/publishing, specifically the Oracle-repackaged io.netty artifacts.

Description

Disclamer: this was generated with AI from a real issue found in a project

Upgrading from cloud.graal.gdk:gdk-parent:4.10.15 to 4.10.17 changes the managed Netty version:

gdk-parent 4.10.15 -> io.netty:*:4.2.15.Final
gdk-parent 4.10.17 -> io.netty:*:4.2.16.Final-oracle-00001

On JDK 17, loading Netty HTTP classes from 4.2.16.Final-oracle-00001 can fail with:

jdk.internal.util.jar.InvalidJarIndexError: Invalid index

At least netty-codec-http-4.2.16.Final-oracle-00001.jar contains a stale META-INF/INDEX.LIST. The index claims that the JAR contains:

io/netty/handler/codec

However, the Oracle-repackaged JAR no longer contains the corresponding ZIP directory entry:

io/netty/handler/codec/

When io.netty.handler.codec.http.HttpResponse is loaded, Java must resolve DecoderResultProvider and DecoderResult from netty-codec-base. The stale index directs the lookup back to netty-codec-http; JDK 17 validates the mapping, finds that it is inconsistent, and throws InvalidJarIndexError.

The upstream io.netty:*:4.2.16.Final artifacts preserve the directory entries and do not fail.

Expected behavior

Oracle-repackaged Netty artifacts should load successfully on supported JDKs and contain either:

• A regenerated, valid META-INF/INDEX.LIST;
• The directory entries referenced by the index; or
• No JAR index.

Actual behavior

Class loading fails on JDK 17 before application or test code can start.

Suggested fix

Republish the affected 4.2.16.Final-oracle-00001 artifacts with a corrected or removed META-INF/INDEX.LIST, then update the GDK BOM/parent to select the corrected artifact revision.

Minimal reproducer

Use JDK 17 and a repository configuration that can resolve the -oracle-00001 artifacts.

pom.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>repro</groupId>
  <artifactId>netty-invalid-jar-index-repro</artifactId>
  <version>1.0-SNAPSHOT</version>

  <properties>
    <maven.compiler.release>17</maven.compiler.release>
    <netty.version>4.2.16.Final-oracle-00001</netty.version>
  </properties>

  <dependencies>
    <dependency>
      <groupId>io.netty</groupId>
      <artifactId>netty-codec-http</artifactId>
      <version>${netty.version}</version>
    </dependency>
    <dependency>
      <groupId>io.netty</groupId>
      <artifactId>netty-codec-base</artifactId>
      <version>${netty.version}</version>
    </dependency>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.14.0</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.3.1</version>
      </plugin>
    </plugins>
  </build>
</project>

src/test/java/repro/NettyJarIndexTest.java:

package repro;

import org.junit.jupiter.api.Test;

final class NettyJarIndexTest {
    @Test
    void loadsNettyHttpResponse() throws ClassNotFoundException {
        Class.forName("io.netty.handler.codec.http.HttpResponse");
    }
}

Run:

java -version
mvn test

With JDK 17 and 4.2.16.Final-oracle-00001, the test fails with:

NettyJarIndexTest.loadsNettyHttpResponse » InvalidJarIndex Invalid index

Control test:

mvn -Dnetty.version=4.2.16.Final test

That passes. I verified both outcomes locally with JDK 17. I also observed that JDK 26 does not throw this error, so the report should specify JDK 17 explicitly.

Inspecting the malformed artifact

unzip -p \
  ~/.m2/repository/io/netty/netty-codec-http/4.2.16.Final-oracle-00001/netty-codec-http-4.2.16.Final-oracle-00001.jar \
  META-INF/INDEX.LIST |
  grep '^io/netty/handler/codec$'

This returns the indexed package. But:

jar tf \
  ~/.m2/repository/io/netty/netty-codec-http/4.2.16.Final-oracle-00001/netty-codec-http-4.2.16.Final-oracle-00001.jar |
  grep '^io/netty/handler/codec/$'

returns nothing. Running the same check against upstream 4.2.16.Final returns the directory entry.

[jasonlyle88]

After my initial post, I realized the issue may be larger than just this one index, so I asked the AI to scan all of the INDEX.LIST files to check for this potential issue and here is what it found:

Additional affected artifacts

Further analysis confirms that this defect is not limited to netty-codec-http.

All 13 Netty modules managed by gdk-parent:4.10.17 were inspected. Eleven of the Oracle-repackaged 4.2.16.Final-oracle-00001 JARs contain invalid META-INF/INDEX.LIST mappings:

Artifact	Invalid index mappings
netty-buffer	7
netty-codec	3
netty-codec-base	10
netty-codec-compression	10
netty-codec-http	10
netty-codec-http2	10
netty-codec-socks	11
netty-handler	9
netty-handler-proxy	10
netty-resolver	5
netty-transport	8

The remaining two artifacts are not affected:

• netty-transport-native-unix-common contains a valid index.
• netty-common does not contain an INDEX.LIST.

In total, 93 invalid mappings were found across 11 artifacts.

The affected indexes contain package or resource-directory mappings that do not correspond to entries in the repackaged JAR. For example:

META-INF/maven
META-INF/native-image
META-INF/versions
io/netty
io/netty/handler
io/netty/handler/codec

This behavior was verified at runtime on JDK 17. Each of the 11 affected artifacts throws InvalidJarIndexError when Java is forced to traverse one of its invalid mappings:

public final class JarIndexProbe {
    public static void main(String[] args) {
        System.out.println(
            ClassLoader.getSystemResource("META-INF/maven/does-not-exist")
        );
    }
}

Example:

javac JarIndexProbe.java

java -cp ".:<path-to>/netty-buffer-4.2.16.Final-oracle-00001.jar" \
  JarIndexProbe

Actual result on JDK 17:

jdk.internal.util.jar.InvalidJarIndexError: Invalid index

Running the same probe against the corresponding upstream artifact:

java -cp ".:<path-to>/netty-buffer-4.2.16.Final.jar" \
  JarIndexProbe

returns the expected result:

null

All matching upstream 4.2.16.Final artifacts passed the same structural and runtime validation.

A separate scan of the project’s complete resolved test classpaths examined 109 unique JARs. Twelve contained JAR indexes, and all were valid after replacing the Oracle-repackaged Netty artifacts with upstream 4.2.16.Final.

These results indicate a common defect in the Oracle Netty artifact-repackaging process, most likely caused by removing ZIP directory entries without regenerating or removing META-INF/INDEX.LIST.

The fix should cover the complete affected artifact set rather than only netty-codec-http.

[karimaazergui]

@jasonlyle88 Thanks for reporting this issue. I will investigate it.

[karimaazergui]

@jasonlyle88 could you please try now with 4.2.16.Final-oracle-00002, that version is containing the fix now.