Bump Gradle from 6.8.3 to 8.10.2 and increase the minimum required
Java version from 8 to 11 (SMACK-953).
The switch from Java 8 to 11 caused some Bytecode portability issues
regarding NIO Buffers. Java changed with version 9 the return type of
some subclasses of Buffer to return the specific Buffer type instead
of the Buffer superclass [JDK-4774077]. For example, ByteBuffer.filp()
previously returned Buffer, while it does return ByteBuffer now.
This sensible change was not reflected by the Android API [1], which
means that AnimalSniffer rightfully started to complain that there is
no method "ByteBuffer ByteBuffer.flip()" in Android, there is only
"Buffer ByteBuffer.flip()", and those are incompatible methods on
Java's Bytecode layer.
As workaround, this changes
return charBuffer.flip().toString();
to
((java.nio.Buffer) charBuffer).flip();
return charBuffer.toString();
to restore the Bytecode portability between Android and Java.
Errorprone also got new checks, of which JavaUtilDate and JdkObsolete
are wroth mentioning.
JavaUtilData basically strongly recommends to use Java's newer time
API over java.util.Date. But since Smack was Java 8 until now,
j.u.Date is widely used.
Similar JdkObsolete mentions obsolete JDK APIs, like data structures
like Vector and Stack. But mostly LinkedList, which should usually be
replaced by ArrayList. And this is what this commit largely does.
JDK-4774077: https://bugs.openjdk.org/browse/JDK-4774077
1: https://issuetracker.google.com/issues/369219141
Instead of Stanza, use StanzaView as constructor parameter type of
StanzaIdFilter. Even though StanzaView also includes builders, the
Stanza ID is even immutable in builders.
For certain use cases, this provides a performance improvement,
probably due better cache locality. However, it comes with the cost of
additional memory consumption.
This was initially suggested by Boris Grozev, who also reported a
significant performance problem of
XmlStringBuilder/LazyStringBuilder. However, the main cause of the
performance probelm was the missing caching of LazyStringBuilder. The
length of the lazy string is now cached by LazyStringBuidler since
70e48300a6 ("[core] Cache length in LazyStringBuilder"), which
accounts for large performance improvement. A significantly smaller
improvement is achieved by this commit and setting
XmlStringBuilder.FLAT_APPEND to 'true'.
Suggested-by: Boris Grozev <boris@jitsi.org>
With 92f253cc74 ("[core] Replace
AbstractXMPPConnection.inOrderListeners") we changes the behavior of
listeners. This commit documents the expectations to the user.
The default local address is often just "the first address found in the list of addresses read from the OS" and this might mean an internal IP address that cannot reach external servers. So wherever possible use the same IP address being used to connect to the XMPP server because this local address has a better chance of being suitable.
This MR adds the above behaviour, and two UTs to test that we use the local XMPP connection IP when connected, and the previous behaviour when not.
Also delete StanzaIdTest since the test was fundamentally weak and
flawed. It does not work anyway, since TestIQ has a fixed stanza ID.
Fixes SMACK-931.
While markdown is easier to write, Smack's markdown documentation was
never tightly coupled with the source. For example, the markdown
documentation never provided links to the actual Java classes and
methods. This poses the risk that the documentation and the code
diverge over time. Furthermore, javadoc is constantly improving (for
example @snippet annotations) and I expect that one will be able to
write javadoc in markdown.
Fixes SMACK-928.
This option is meant a quick and dirty hack until
XMPPConnection.sendStanza() throws a dedicated Exception in case the
connection's outgoing queue is full.
Using any of the two methods is error prone, see 0e0c0a4093 ("[tcp]
Fix handling in connection exceptions when resuming a stream"), as one
can easily forget to check for connection exceptions after it
returned. There are also no longer any call sites of those methods.
Let's inline both variants of this method.
Smack historically provided fine-grained options for the
SSLContext. This is however not flexible enough, as an option to
specifiy the KeyManager(s) was missing.
This deprecated the options for keystore path, keystore type, and
PKCS#11 library, in favor of an option to set the KeyManager, which
could be aware of the keystore path and type, and the PKCS#11
library. At some point, Smack may provide some high-level methods to
create a KeyManager from provided keystore path, keytsore type and
PKCS#11 library.
Previously, if a SmackFuture both was successful and unsuccessful, it
was possible that the onSuccess() callback was invoked twice.
Reported-by: Boris Grozev <boris@jitsi.org>
