modbus4j is a Java Modbus implementation still served from a vendor Maven repository

What the library covers

modbus4j is described as a high-performance and ease-of-use implementation of the Modbus protocol written in Java, by Infinite Automation Systems and Serotonin Software. The description is compact and every clause in it is a design decision.

The four transports are the first. Modbus is a family of serial and network protocols rather than one protocol, and the ASCII encoding over a serial line, the binary RTU encoding over a serial line, and the TCP and UDP framings over a network are different enough that a library either implements all of them or forces you to pick one. This one does all four.

The master and slave roles are the second. Modbus is a request and response protocol where one side polls and the other answers, and the same device is often both: a gateway that polls upstream sensors and serves downstream controllers. Supporting both roles means the framing, the transaction identifiers and the exception handling have to be correct in both directions, which is where a single role implementation tends to be thin.

Automatic request partitioning is the third, and it is the feature that matters most in practice. A Modbus read request carries a starting address and a quantity of registers, and a device has a per request limit, so a logical read of ten thousand registers has to be split into several physical requests and the responses reassembled. Doing that by hand in application code is tedious and easy to get wrong, and the library does it for you.

Response data type parsing is the fourth. The protocol returns raw bytes, and the library turns them into the types the caller asked for, so the application works with numbers and booleans rather than with byte arrays and shift operations.

The audience is a Java developer with industrial or building automation hardware, and the framing of the project points at a specific kind of user: a company that sells the hardware and needs the protocol stack for its own products.

The build is Ant and Maven at the same time

The repository layout shows a project that has been worked on for a long time and carries the build systems of two eras.

There is a build.xml, which is an Ant build, alongside a pom.xml, which is a Maven build. There are also.classpath and.project files and a.settings/ directory, which are Eclipse project metadata, so the project was developed in Eclipse as well as being buildable by Ant and by Maven. The Ant build carries a separate file, build-cdc.xml, and the source tree is split into src/, src_cdc/, src-opt/ and src_test/, with a lib-opt/ directory of optional libraries and a release/ directory.

That naming pattern is worth reading carefully rather than dismissing as legacy. The src-opt/ and lib-opt/ directories suggest optional pieces that are not part of the core build, most likely the transports or codecs that need a third party library, and src_cdc/ is a separate source root for the same reason, a variant of the code built for a different configuration. A project that keeps optional components in their own source root is a project where the optional things are genuinely optional, and where a consumer who needs one of them has a defined way to get it.

The RELEASE-NOTES file at the root and the license.txt are the other two things to look at, and for a library of this age they are the two most useful files in the repository after the README.

The practical consequence for a user is that there is more than one way to build this, and the one to use is the Maven path, since that is what the README documents and what the published artifacts come from.

Installing it means adding two Maven repositories

The installation instructions start with the repository configuration rather than the dependency. There are two repositories, one for snapshots and one for releases, and they are mutually exclusive in their configuration, which is the detail that trips people up.

The snapshot repository enables snapshots and disables releases:

<repository>
    <releases>
        <enabled>false</enabled>
    </releases>
    <snapshots>
        <enabled>true</enabled>
    </snapshots>
    <id>ias-snapshots</id>
    <name>Infinite Automation Snapshot Repository</name>
    <url>https://maven.mangoautomation.net/repository/ias-snapshot/</url>
</repository>

And the release repository is the mirror image of that:

<repository>
    <releases>
        <enabled>true</enabled>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <id>ias-releases</id>
    <name>Infinite Automation Release Repository</name>
    <url>https://maven.mangoautomation.net/repository/ias-release/</url>
</repository>

The dependency itself is short, and the version in it is the one to note:

<dependency>
    <groupId>com.infiniteautomation</groupId>
    <artifactId>modbus4j</artifactId>
    <version>3.0.3</version>
</dependency>

The group id is com.infiniteautomation, the artefact is modbus4j, and the documented version is 3.0.3. Both repositories are on the same host, maven.mangoautomation.net, under separate paths, and the naming of the organisation, MangoAutomation, is the same project that publishes the repository, so the repository is a side channel of a commercial vendor's own build infrastructure rather than a general purpose public repository.

That has an operational consequence. Adding a vendor hosted repository to your build means your dependency resolution now depends on that host being up and on your organisation accepting that as a supply chain dependency, and it means the snapshot repository should be disabled in a production build, which the configuration above already does correctly.

The version numbers do not line up, and that is the thing to check

There is a mismatch here, and any adopter will trip over it.

The repository has one tagged release, 2.0.7, dated 2014-12-03, and the README's dependency example asks for version 3.0.3 from the vendor's Maven repository. The last push to the repository was on 2026-06-15 and the repository is not archived, so there is recent activity, but the release tags stop in 2014.

The gap has an obvious explanation, which is that the source of truth for released artefacts is the vendor's Maven repository rather than the GitHub tags. This is a common pattern for libraries that ship from a company's build system, and it means the GitHub release list is not the version history. It also means that when you read the repository you are reading a source tree whose relationship to the published 3.0.3 artefact you can only infer, unless the RELEASE-NOTES file says so.

The RELEASE-NOTES file is therefore the file to read first, alongside the CHANGELOG equivalent, to find out what changed between the tag you can see and the artefact you would actually depend on. The repository root also holds a README.txt next to README.md, which in projects of this vintage is often the older, more technical version of the same document, and it may carry the version history the Markdown readme omits.

For a build, the practical rule is simple: depend on the Maven artefact version, not on a Git tag, and expect to read the notes rather than a changelog in the usual place. For a reviewer, the question to ask the vendor or the community is what the state of the main branch is relative to 3.0.3, because that is the thing the tags do not tell you.

Support comes through a vendor forum, and there is a commercial track

The support arrangement is stated in one line: for support and general help, see the forum at the Infinite Automation community, in the Modbus4j general discussion category.

That tells you something. The library is maintained by two companies, Infinite Automation Systems and Serotonin Software, and the community forum belongs to Infinite Automation, so the open discussion around the library sits alongside the commercial product support of the company that also publishes it. For a user of the library this is workable and for a user of the company it is a natural arrangement.

The commercial track is explicit as well: commercial licences are available by contacting an address at radixiot.com. Combined with the GPL-3.0 licence on the source, that is the standard shape for an industrial library where a company wants an open core with a paid path for commercial redistribution or for support obligations, and it means the licence of the code you use is GPL-3.0 while a commercial arrangement, if you need one, is a separate conversation.

The audience, then, is split. There are people who want a Modbus stack for their own service and are happy with a GPL library and a forum, and there are companies that need the same stack with support and a licence that fits their distribution model. The second group is who the commercial offer is for.

The licence itself is GPL-3.0, with the licence text in license.txt at the repository root, and it is a normal copyleft licence with the usual implication for a library: if you modify it and distribute the result, the derivative carries the same terms, and a service that uses it over a network is not a distribution, so most service deployments are unaffected. Whether that reading matches your own legal advice is not something this repository can answer, and it is a question to ask before you build on it.

Editorial conclusion

modbus4j suits a Java team integrating Modbus devices, in particular a team already using Infinite Automation products who want the same protocol stack in their own services, and it suits a project that needs master and slave roles over several transports. It is the wrong choice if you need an actively released library, because the only tagged release in the repository is 2.0.7 from December 2014 while the published artifact is 3.0.3, and a poor match if you need support from the maintainers, because the project routes general support through a vendor forum and sells commercial licences separately. Before adopting, confirm which artifact version the repository actually serves, check the RELEASE-NOTES for the gap between the two, and decide whether the vendored Maven repository is acceptable in your build.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. MangoAutomation/modbus4j on GitHub
4. README
5. Releases