Now that FormWriter, with its write() method, is gone, there is no
reason the FormReader method should still be named read(). Renaming to
getField() as this is what DataForm also uses.
`mgr.getNode(...)` method is not supposed to throw any type
of exception. It threw two kinds of exceptions: `NotConnectedException`
and `SmackException`.
By using `ThreadedDummyConnection.newInstance()` method,
`NotConnectedException` can be removed. And `SmackException`
can be removed by correctly building the DiscoverInfo packet.
Apply builder pattern to form fields and replace getVariable() with
getFieldName(). Refer to the field name as "field name" instead of
"variable" everyone, just as XEP-0004 does.
Improve the high-level form API: introduce FilledForm and FillableForm
which perform stronger validation and consistency checks.
Also add FormFieldRegistry to enable processing of 'submit' forms
where the form field types are omitted.
Smack also now does omit the form field type declaration on 'submit'
type forms, as it is allowed by XEP-0004.
The FaultTolerantNegotiator is the reason why Smack replies in a
non-standard way to file transfer requests: Smack puts two values in
the stream-method field, while the field is a list-single field,
i.e. a field which only allows one value.
Even if what Smack does is probably better, as it allows for a
fallback in case the bytestream transport fails, it is not standard
compliant. And, Jingle provide a proper fallback specification for
file transfers.
Fixes SMACK-561.
Those configurations where removed with version 1.13 (2010-07-12) of
XEP-0060.
This change is part of the effort to upgrade Smack's PubSub
implementation (SMACK-364).
In order to truely stay Java 8 compatible, declaring a source and
target compatiblity is not sufficient. Source compatiblity means that
the input, i.e. the code written in Java is compatible with that
particular version of the Java Language Specification (JLS). And
target compatibitliy means that the produced Java bytecode is
compatible with that particular version of the Java Virtual Machine
Specificiation (JVMS).
But there is actually a third dimension: the runtime
library (rt.jar). If signatures of methods change over java releases
within the runtime library, then the produced bytecode, may contain
calls to methods that do not exist with that exact same signature in
older java versions.
For example the family of Buffer subclasses changed the return value
of certain functions, for example flip() to not return Buffer, but the
concrete type of the current instance, e.g. CharBuffer.
If we compile now with a newer JDK, where the return type is
CharBuffer and not Buffer, then executing on an older JDK, where the
return type is Buffer, then we get java.lang.NoSuchMethodError(s)
thrown at us.
Fixes SMACK-651.
