Here some of the reasons, why in my opinion Openfire isn’t as attractive:
First, I think it’s not that easy to get started with Openfire, due to the following reasons:
Until recently it had no modern build system, it was hard (or still is) to correctly setup Openfire in your build environment, because you have to do it manually (e.g. add all dependencies from build/lib folder).
It still doesn’t use a well-known directory structure (like src/main/java), which would be familiar to new devs.
On top of that, all the plugins.
If you get it done, it’s hard to get an overview.
I once counted the lines of code, I don’t remember the numbers, but it was huge, I think it were around 320000 LOC (only Java classes, without comments), additionally all the JSP files and other stuff.
The package structure is also a mess.
Second, the code is often cumbersome and repetitive.
As an example, take a look at PubSubEngine.java. I think I counted 49 occurrences of the namespace “http://jabber.org/protocol/pubsub”, I don’t like how DOM4J elements are recreated from scratch everytime.
Another example is “urn:xmpp:delay”, every time you need this, you have to know the XML schema and use things like:
(There are like 20 occurrences of things like that).
Third, it hardly uses standards or modern frameworks, a few examples:
- Jetty WebSocket API instead of javax.websocket
- Dom4j, I think it still uses
- Apache MINA, which seems quite dead since 2009
- No JPA, but instead manually doing all DB stuff with JDBC
- Custom cache implementation
- Many custom solutions, e.g. for date formats, base64 or other generic utility.
I understand, that it’s hard to update any of these things, especially due to all the third-party plugins out there, which probably would break.
Fourth, there are hardly any (unit) tests.
If you develop something, you can never be sure, that you break something, which probably discourages work on the project.