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.
Refactored using
find . -type f -name "*.java" |\
xargs sed -i -E |\
's/\.createStanzaCollectorAndSend\((\w+)\)\.nextResultOrThrow\(\);/.sendIqRequestAndWaitForResponse(\1);/'
and some manual refactoring.
This also resulted in a refactoring of the Providers and parsing
Exceptions. NumberFormatException and ParseException can now be thrown
directly, the wrapping in a SmackParsingException is down at a higher
layer, i.e. in AbstractProvider.
This also removes the powermock dependency. Although powermock is a
fine library, it currently prevents dropping Junit4. And since we only
use the Whitebox API of powermock, this simply replaced powermock's
Whitebox with our own.
and FileTestUtil in favor of commons-io. This is required because
Eclipse won't put src/test code into the classpath of src/main
code (even though gradle was configured with an according
dependency).
- Reduce the amount of types that are subtypes of NamedElement. See
javadoc of NamedElement for rationale.
- Work more with XmlEnvironment in XmlStringBuilder.
- Some minor changes to XmlStringBuilder API.
Introducing Smack's own XmlPullParser interface which tries to stay as
compatible as possible to XPP3. The interface is used to either wrap
StAX's XMLStreamReader if Smack is used on Java SE, and XPP3's
XmlPullParser if Smack is used on on Android.
Fixes SMACK-591.
Also introduce JUnit 5 and non-strict javadoc projects.
The NPE is caused by an inbound presence stanza without the 'from'
attribute set. The stacktrace of the NPE is:
FATAL EXCEPTION: Smack Cached Executor
Process: de.fhg.ivi.senetz.mobile.android.mbk.debug, PID: 13365
java.lang.NullPointerException: Attempt to invoke virtual method 'int java.lang.Object.hashCode()' on a null object reference
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:944)
at org.jivesoftware.smack.roster.Roster.getPresencesInternal(Roster.java:374)
at org.jivesoftware.smack.roster.Roster.getOrCreatePresencesInternal(Roster.java:388)
at org.jivesoftware.smack.roster.Roster.access$1100(Roster.java:94)
at org.jivesoftware.smack.roster.Roster$PresencePacketListener$1.run(Roster.java:1519)
at org.jivesoftware.smack.AsyncButOrdered$Handler.run(AsyncButOrdered.java:121)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
Thanks to Marcel Heckel for reporting this.
Fixes SMACK-861.
and deprecate createEntry().
createEntry() would also send a subscription request which may is
suprising given that you can also create an roster item without having
to send a subscription request out.
This also fixes a bug in
LowLevelRosterIntegrationTest.testPresenceEventListenersOffline()
where createEntry() was used, which would also trigger a presence
subscription request which in turn made the test fail if the
SubscribeListener of ensureSubscribedTo() was not yet set
up. So the test would fail depending on the timing.
This commit adds
- SmackReactor / NIO
- a framework for finite state machine connections
- support for Java 8
- pretty printed XML debug output
It also
- reworks the integration test framework
- raises the minimum Android API level to 19
- introduces XmppNioTcpConnection
Furthermore fixes SMACK-801 (at least partly). Java 8 language
features are available, but not all runtime library methods. For that
we would need to raise the Android API level to 24 or higher.
Fix for SMACK-841
Since Smack 4.2.4, the getPresencesInternal method in the Roster class
can return a LruCache object, which is a LinkedHashMap with access
order. This means that any access using get or getOrDefault will be a
modification of the Map. If you loop over the keySet of the Map and
there are more than one, the second call to get will throw a
ConcurrentModificationException!
Since the keys are only used here to obtain the corresponding
values, the simplest solution is to just loop over the values instead.
