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
Due to a change in Smack 4.5.0-beta2, test execution of (all) SINT tests is aborted when `FormTest` is executed.
It appears that Smack now has more strict argument validation when setting thread IDs on message stanzas. This validation should not fail for the tests that are shipped with Smack.
This is the stack trace when executing the failing test (which no longer occurs after the change in this commit is applied):
```
Exception in thread "main" java.lang.IllegalArgumentException: thread must not be null nor empty
at org.jivesoftware.smack.util.StringUtils.requireNotNullNorEmpty(StringUtils.java:533)
at org.jivesoftware.smack.packet.Message$Thread.<init>(Message.java:326)
at org.jivesoftware.smack.packet.MessageBuilder.setThread(MessageBuilder.java:70)
at org.jivesoftware.smack.packet.MessageBuilder.setThread(MessageBuilder.java:66)
at org.jivesoftware.smackx.xdata.FormTest.testFilloutForm(FormTest.java:133)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.lambda$runTests$0(SmackIntegrationTestFramework.java:476)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.runConcreteTest(SmackIntegrationTestFramework.java:556)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework$PreparedTest.run(SmackIntegrationTestFramework.java:764)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.runTests(SmackIntegrationTestFramework.java:544)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.run(SmackIntegrationTestFramework.java:277)
at org.igniterealtime.smack.inttest.SmackIntegrationTestFramework.main(SmackIntegrationTestFramework.java:115)
```
After a room is destroyed, the MultiUserChat-stored representation of the 'join' state of any occupant should be updated to reflect that the user is no longer in the room.
This fixes a problem where an occupant (that not itself triggered the destruction) appears to continue be part of a room after its destruction.
Additional integration test assertions are added to check for the invalid state fixed by this commit.
fixes SMACK-949
When an occupant gets its membership revoked in an members-only room, the appropriate method of registered ParticipantStatusListeners should be invoked.
After test execution, the OpenPGP for XMPP integration tests should clean up the data published via PEP. This prevents these tests from interfering with other tests.
Additional cleanup of test fixtures:
- various tests that change roster/subscription get a roster-reset
- one test that registers a listener now deregisters that listener
The test that's modified in this commit asserts that upon MUC join, stanzas are received in a particular order.
The previous implementation depended on several event listeners (one for presence, one for messages) that did not always fire in the same order in which the corresponding stanzas arrived. This made the approach unsuitable to reliably test the order in which stanzas arrive.
This commit stops using Smack's MUC API when trying to collect the order in which stanzas arrive. Instead, it joins a chatroom and listens for its stanzas using basic stanza handling. As this uses exactly one stanza listener, that's guaranteed to be invoked in order of stanza arrival, any synchronicity issue in the previous implementation no longer applies.
Making use of the new assertion handling for MultiResultSyncPoint, the integration test that uses that implementation can now get improved assertion messages. This will allow users to more quickly determine why a test is failing.
When occupant One waits for occupant Two to join the room, One should register the corresponding listener _before_ Two joins.
Without this, a race conditions occurs, where Two could have joined the room before One registered the listener, thus missing the event.
The test was originally implemented when version 1.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.3.0.
The test was originally implemented after the most current version of the XEP was published, making it plausible that this implementation matches the current version of the XEP: 0.3.
The test was originally implemented when version 1.15.7 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications (with regards to the functionality that is the subject of the tests), making it plausible that this implementation matches the current version of the XEP: 1.26.0.
The test was originally implemented when version 2.0 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 2.0.1.
The test was originally implemented when version 0.1.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 0.2.0.
These tests were originally implemented when versions 0.2.1 and 0.3.0 of the XEP were the most current version. Later versions of the XEP do significantly modify the specifications, making it plausible that this implementation matches the version of the XEP that was the most recent version at the time the test was created: 0.3.0
The test was originally implemented when version 1.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.2.
The test was originally implemented when version 1.25 of the XEP was the most current version. Later versions of the XEP do significantly modify the specifications, but the test implementation has had continuous changes over time too. This makes it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.1 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented when version 1.34.2 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 1.34.6.
The test was implemented after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.2.1
The test was originally implemented when version 0.5.1 of the XEP was the most current version. The Smack code that is being tested defines a namespace that was introduced in 0.6, making it plausible that this implementation matches the version of the XEP, followed by some editorial changes: 0.6.3 (which is _not_ the latest version of the XEP).
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.1.
The test was implemented when version 0.4 of the XEP was the most current version. Later versions of the XEP do not significantly modify the specifications, making it plausible that this implementation matches the current version of the XEP: 0.5.1.
The test was implemented when version 0.3.1 of the XEP was the most current version. The Smack code that is being tested defines a namespace that was introduced in 0.4.0, making it plausible that this implementation matches that version of the XEP: 0.4.0 (which is _not_ the latest version of the XEP).
The test was implemented years after the most current version of the XEP was published, making it plausible that the implementation matches that version of the XEP: 1.9.
