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);
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:
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