java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer; in InsecureNonceChaCha20Poly1305Base on JDK8

Hi,

We are using Tink for Java.

One of our projects is still using Java 8.

We noticed a binary-compatibility issue when upgrading from Tink 1.18.0 to 1.19.0.

Hereunder is the stacktrace:

java.lang.NoSuchMethodError: java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
	at com.google.crypto.tink.aead.internal.InsecureNonceChaCha20Poly1305Base.encrypt(InsecureNonceChaCha20Poly1305Base.java:98)
	at com.google.crypto.tink.aead.internal.InsecureNonceXChaCha20Poly1305.encrypt(InsecureNonceXChaCha20Poly1305.java:26)
	at com.google.crypto.tink.subtle.XChaCha20Poly1305.rawEncrypt(XChaCha20Poly1305.java:63)
	at com.google.crypto.tink.subtle.XChaCha20Poly1305.encrypt(XChaCha20Poly1305.java:70)

It seems to come from the fact that in Java 8, ByteBuffer does not override the #position(int) method of Buffer, while on Java 11 it does.

Therefore, it would seem that Tink 1.19.0 has been compiled with JDK11 (or beyond) with target level set to 1.8.

However, while the Java sources are the same, the bytecode generated is not the same as before and links to the ByteBuffer#position(int) method of JDK11 which does not exist on JDK8.

Maybe this should be seen as a compiler bug?

A "silly" fix to keep the compatibility with JDK8 would be to force linking to the right method with

    chacha20.encrypt(output, nonce, plaintext);
    ((Buffer) output).position(firstPosition);

Start at InsecureNonceChaCha20Poly1305Base.encrypt, especially line 98 in the stack trace, and compare the ByteBuffer.position(int) call with the suggested Buffer cast. Reproduce the linkage failure on JDK 8 and verify the relevant XChaCha20Poly1305 path; done means Tink 1.19.0 remains binary-compatible with JDK 8.