As always you can find the artifacts in Maven Central:
<dependency> <groupId>rocks.xmpp</groupId> <artifactId>xmpp-core-client</artifactId> <version>0.7.0</version> </dependency> <dependency> <groupId>rocks.xmpp</groupId> <artifactId>xmpp-extensions-client</artifactId> <version>0.7.0</version> </dependency>
Release highlights are support for WebSocket connection, the new XMPP Address Format (RFC 7395), asynchronous API for IQ queries and XEP-0198: Stream Management (which is still a bit experimental).
Some API has also been revised for less ambigious and easier usage, e.g. timeouts are now represented by java.time.Duration
instead of a int/long
(which somtimes were seconds, sometimes milliseconds) and the xml:lang
attribute is now represented by java.util.Locale
instead of String
to prevent improper usage.
- Add support for XEP-0198: Stream Management
- Add support for WebSocket connection method (RFC 7395).
- Update Jid class to the new XMPP Address Format (RFC 7622)
- IQ queries can now be executed asynchronously (non-blocking) using Java 8’s
java.util.concurrent.CompletableFuture
API. - Represent
xml:lang
attributes asjava.util.Locale
, not asString
. - Represent timeouts as
java.time.Duration
instead ofint/long
for better clearness. - Add a very minimalistic DNS resolver for resolving SRV and TXT records in order to remove the dependency to com.sun.* classes.
- Add more
ReconnectionStrategy
implementations. - Check connected state of socket before connecting (to prevent
SocketException
when aSocketFactory
provides a connected socket) - Add
XmppSession#isAuthenticated()
method. - Add static
XmppSession#addCreationListener()
method to allow to listen for newly created sessions. - Update XEP-0080 to version 1.9 (add altaccuracy element).
- Add API to destroy a MUC room without a reason.
- More documentation, e.g. clarify the use of
ConnectionConfiguration#secure()
- Don’t include an empty body in Message Delivery Receipts.
- Add correct XML names to component namespace stanzas.
- Eagerly release unused port to prevent ports-leaks due to delayed GC
- Improve thread-safety during
connect()
and login() - Fix encoding issues, caused by missing UTF-8 encoding, mainly in the debugger.
- XEP-0033: Address should have extensions.
- Add workaround for a JDK bug causing memory issues and high CPU.
- Add documentation for custom SASL authentication.
Thank you so much for this library. It's such a pleasure to work with it.
ReplyDeletePrototyping is extremely easy. Just today I wrote a server-feature tester in like <2 hours. (https://github.com/iNPUTmice/ComplianceTester)
Thanks for your feedback, you're welcome!
DeleteHi Christian,
ReplyDeleteI tried to get my hands dirty with babbler today and found it good to use.
However, the library is compatible with JAVA 8 only, so could not use it in an Android environment. Can you please release a Java7 compatible version of the library so that it could be used on Android. Android currently supports JAVA 8 partially which makes it difficult to use.
Thanks
Vaibhav
Hi Vaibhav,
Deletesorry, it's nearly impossible to release a Java 7 version. Too many Java 8 classes are in use (especially java.time, java.util.concurrent.CompletionStage/CompletableFuture).
Furthermore there are classes, which are not supported in Android, even if it runs on Java 7: e.g. javax.security.sasl.SaslClient, javax.xml.bind (the whole JAXB stuff) and package annotations.
I want to make new XMPP server for our company. But I don't know and did't do XMPP programming. Can I use this library for server-side?
ReplyDeleteThank you.
Theoretically you could use parts of this library for server programming. Everything in xmpp-core module (jar) should be usable in a server environment. It only contains the classes which map to XML.
DeleteHowever, most parts are only written for clients.
I've once started a prototypical server with it, using a network library and Aalto XML parser for NIO/non-blocking XML parsing.
Writing your own XMPP server is possible, but it's a lot of work.
Hi Christian.
DeleteThank you for your kind reply. I got your point regarding babbler.
I have one more question.
If you make chat server using XMPP protocol for comercial project, what's the best way? Custom some open source server? or Make new one?
I'd probably customize some open source server like Openfire. Creating your own is cool and flexible, but a lot of work.
Delete(Not sure if the message I submitted a few days ago got eaten, but here's another one)
ReplyDeleteHi. Is there anyway, using Babbler, to inject server notices into both a MUC and a private chat? Further, would there be any way to target these notices (visible to everyone, or just this person, or that group, etc)? I've experimented, and I think the only solution is to have a hidden system user (which wouldn't work in an OTR private chat), but I'd prefer a cleaner solution if there is one.
Thanks!
I don't think it's possible. I think you should have a server side plugin for this use case, which can send these server messages.
DeleteHi Christian,
ReplyDeleteYou did/do really a nice job with this library! The better I tried so far... But I do not really like how PubSub events are managed. If I don't miss something, and according to your example, these events should be handled in a "xmppClient.addInboundMessageListener" which makes this method a large "if/else" thing if you want to process events coming from many different nodes as well as "classical" messages. Isn't it possible to add the handling of events directly by the PubSubNode, i.e. something like "pubSubNode.addEventListener"?
It would be also nice to be able to make use of JAXB to parse event.
Thanks.