Скачать или смотреть Understanding VerifyError in Java 22 ClassFile API: The Int vs Reference Type Confusion

Learn why Java 22's ClassFile API can throw VerifyError due to method signature mismatches involving primitive and reference types, and how to fix it.
---
This video is based on the question https://stackoverflow.com/q/79477644/ asked by the user 'dloop' ( https://stackoverflow.com/u/24044639/ ) and on the answer https://stackoverflow.com/a/79477673/ provided by the user 'rzwitserloot' ( https://stackoverflow.com/u/768644/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: Interpreting Java Classfile API verify error

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/l...
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license.

If anything seems off to you, please feel free to drop me a comment under this video.
---
Interpreting VerifyError When Using Java 22 ClassFile API

When working directly with Java's low-level ClassFile API (introduced in Java 22), encountering a VerifyError during JVM bytecode verification can happen if method signatures or bytecode instructions mismatch types. This post clarifies a common confusion: the difference between primitive int and reference types labeled like Lint; in JVM signatures.



The Problem

While building a method with the ClassFile API, the developer tried to emit bytecode like this:

[[See Video to Reveal this Text or Code Snippet]]

This loads a local variable slot 2, which was declared as int. However, the JVM throws:

[[See Video to Reveal this Text or Code Snippet]]

The method signature listed is:

[[See Video to Reveal this Text or Code Snippet]]

Here [D means double[], but Lint; looks unusual. This causes the mismatch error.



What Does The Signature Mean?

JVM method descriptors encode types like this:

Primitive types have single letters: I for int, D for double.

Reference types (i.e., classes and interfaces) are prefixed with L and suffixed with ;.

Example: Ljava/lang/String; represents the String class.

Your signature sumArrD([DLint;)D breaks down to:

[D → double[]

Lint; → a reference type named int (not the primitive int)

D → return type double

Why is Lint; strange?

It means a reference type literally named int, which does not exist in Java.

This is not the same as primitive int.



Why the VerifyError Occurs

The JVM expects aload operation to load reference types and iload for primitives like int.

iload(2) assumes slot 2 is a primitive int.

But the slot 2 type is actually a reference (Lint;), causing verification to fail.



The Root Cause: Wrong Method Descriptor Construction

This typically happens if you defined the method signature incorrectly using ClassFile API types.

Incorrect code snippet example:

[[See Video to Reveal this Text or Code Snippet]]

Here, ClassDesc.of("int") treats "int" as a class name, not a primitive.

Correct approach:

Use the provided constant descriptors for primitives:

[[See Video to Reveal this Text or Code Snippet]]

Then the method descriptor should be:

[[See Video to Reveal this Text or Code Snippet]]

which corresponds to:

[[See Video to Reveal this Text or Code Snippet]]



Key Takeaways

The JVM method descriptor syntax is precise: I for primitive int, L<classname>; for reference.

When building method signatures, never create a ClassDesc for primitives by their name string.

Use constant descriptors for primitives available in the ClassFile API.

Use iload for primitive locals and aload for reference locals.



By carefully creating correct method signatures with primitive descriptors and matching the load instructions (iload vs aload), you can avoid VerifyError caused by type mismatches.