skylot/jadx · warning · JadxRuntimeException

Not yet supported

Error message

Not yet supported

What it means

In CustomLambdaCall.buildLambdaMethodCall(), the lambda's implementation method handle (values[4]) is a field handle rather than a method handle. JADX currently only implements method-based lambda metafactory calls, so a field handle (e.g. a field-based functional interface target) is explicitly unsupported.

Source

Thrown at jadx-core/src/main/java/jadx/core/dex/instructions/invokedynamic/CustomLambdaCall.java:57

		if (mthRef.getType() != EncodedType.ENCODED_METHOD_HANDLE) {
			return false;
		}
		IMethodHandle methodHandle = (IMethodHandle) mthRef.getValue();
		if (methodHandle.getType() != MethodHandleType.INVOKE_STATIC) {
			return false;
		}
		IMethodRef methodRef = methodHandle.getMethodRef();
		if (!methodRef.getParentClassType().equals("Ljava/lang/invoke/LambdaMetafactory;")) {
			return false;
		}
		String mthName = methodRef.getName();
		return mthName.equals("metafactory") || mthName.equals("altMetafactory");
	}

	public static InvokeCustomNode buildLambdaMethodCall(MethodNode mth, InsnData insn, boolean isRange, List<EncodedValue> values) {
		IMethodHandle callMthHandle = (IMethodHandle) values.get(4).getValue();
		if (callMthHandle.getType().isField()) {
			throw new JadxRuntimeException("Not yet supported");
		}
		InvokeCustomNode resNode = buildMethodCall(mth, insn, isRange, values, callMthHandle);
		int resReg = insn.getResultReg();
		if (resReg != -1) {
			resNode.setResult(InsnArg.reg(resReg, mth.getReturnType()));
		}
		return resNode;
	}

	@NotNull
	private static InvokeCustomNode buildMethodCall(MethodNode mth, InsnData insn, boolean isRange,
			List<EncodedValue> values, IMethodHandle callMthHandle) {
		RootNode root = mth.root();
		IMethodProto lambdaProto = (IMethodProto) values.get(2).getValue();
		MethodInfo lambdaInfo = MethodInfo.fromMethodProto(root, mth.getParentClass().getClassInfo(), "", lambdaProto);

		MethodHandleType methodHandleType = callMthHandle.getType();
		InvokeCustomNode invokeCustomNode = new InvokeCustomNode(lambdaInfo, insn, false, isRange);

View on GitHub (pinned to e738a26571)

Solutions

1. Upgrade JADX — field-handle lambda support may be added in future releases.
2. Check the JADX issue tracker / changelog for field-based lambda support.
3. Use --show-bad-code to get the rest of the method; the lambda site will appear as an error comment.
4. Request the feature upstream with the offending class as a sample.

// Detect a field-based lambda before calling buildLambdaMethodCall (internal use).
IMethodHandle h = (IMethodHandle) values.get(4).getValue();
boolean unsupported = h.getType().isField();

try {
    jadx.load();
} catch (JadxRuntimeException e) {
    if (e.getMessage().equals("Not yet supported")) {
        log.warn("Field-based lambda not yet supported by JADX; use --show-bad-code", e);
    } else throw e;
}

When it happens

Trigger: An invoke-custom / LambdaMetafactory bootstrap where the 5th call-site value (the actual implementation member) is a field handle (STATIC_GET/PUT or INSTANCE_GET/PUT) instead of an invoke handle.

Common situations: Bytecode produced by newer Java toolchains that emit field-based lambda targets, or unusual generated code. This is a feature gap, not a corruption error.

Related errors

• Field handle not yet supported
• Unsupported method handle type: {}
• Failed to generate 'invoke-custom' instruction:
• Unexpected argument type in lambda call:
• Failed to get call site for insn: {}

AI-assisted analysis of skylot/jadx@e738a26571 (2026-08-14). Data as JSON: /api/errors/44935481b36a4a57. Report an issue: GitHub.