QuickFIX/J: a Java messaging engine for the FIX protocol

What the project is

QuickFIX/J is a full featured messaging engine for the FIX protocol, and it is the official project repository. The protocol it implements is the Financial Information eXchange standard, a messaging standard developed specifically for the real-time electronic exchange of securities transactions, and it is a public-domain specification owned and maintained by FIX Protocol Ltd. The engine covers FIX versions 4.0 through 5.0SP2 and FIXT1.1, plus FIXLatest, and it is a 100% Java open source implementation of the popular C++ QuickFIX engine. The primary language is Java, the default branch is `master`, and the releases are QFJ_RELEASE_3_0_2 on 2026-08-04, QFJ_RELEASE_2_3_3 on 2026-07-21 and QFJ_RELEASE_3_0_1 on 2026-05-12, so both a 2.x and a 3.x line are being maintained. The last push was on 2026-10-13. The homepage is quickfixj.org and the artifacts are published to Sonatype Central as `org.quickfixj:quickfixj-core`.

Building it, with three levels of test coverage

The build instructions give three options, differing only in how much of the test suite you run. The fastest skips the tests entirely:

$ mvnw clean package -Dmaven.javadoc.skip=true -DskipTests -PskipBundlePlugin,minimal-fix-latest

The slower variant skips only the acceptance test suite, using `-DskipAT=true` instead of `-DskipTests`, and the slowest runs everything by dropping both flags. The `-PskipBundlePlugin,minimal-fix-latest` profile is part of every command, and the note explains that if you want to use the resulting JARs in an OSGi environment you have to omit the `skipBundlePlugin` option. The Maven wrapper `mvnw` is committed, so a clone builds without a local Maven installation. There is also a note about importing the project into an IDE, and it is a real one: when the project is first created it does not have the generated message classes, so compile errors occur, and the advice is to compile once on the command line before importing into the IDE.

The module layout, and what each one is for

The repository is a multi-module Maven build, and the module names describe the layers. `quickfixj-core` is the engine itself, `quickfixj-base` holds the shared base classes, `quickfixj-messages` contains the message and field definitions, and `quickfixj-dictgenerator` generates the data dictionaries. `quickfixj-examples` holds the example applications. `quickfixj-orchestration` is about running the engine, and there are two performance modules, `quickfixj-perf-test` and `quickfixj-stress-test`, which tell you the project is tested against both throughput and load. `quickfixj-all` is an aggregate module and `quickfixj-distribution` assembles the release. The `src/` directory at the top level holds the project-level resources. The `customising-quickfixj.md` document at the root is the pointer to how to adapt the engine, and the configuration options are documented in the quickfixj-core user manual, at a URL that lives in the core module's own doc directory, which is where the engine's generated documentation ends up.

The Application interface, and the callbacks that matter

You write a QuickFIX/J application by implementing the `quickfix.Application` interface, and the documentation says the function you should be most aware of is `fromApp`, which is where every application level request arrives. The rest of the callbacks divide the session lifecycle from the message flow. `onCreate` is called when the engine creates a new session, and a session comes into and remains in existence for the life of the application whether or not a counterparty is connected, so you can begin sending messages to it immediately, and if nobody is logged on the messages are sent when a connection is established. `onLogon` notifies you when a valid logon has been established, and `onLogout` when a session is no longer online, whether through a normal logout exchange, a forced termination or a loss of network connection. `toAdmin` and `fromAdmin` cover administrative messages in both directions, and `fromAdmin` is where you do extra validation on a logon, such as checking passwords, with a `RejectLogon` exception disconnecting the counterparty.

DoNotSend, PossDupFlag and the resend path

The `toApp` callback carries the one piece of business logic that every FIX application ends up needing. It is a callback for application messages being sent to a counterparty, and if you throw a `DoNotSend` exception in it, the application will not send the message. The documented use is a message the application has been asked to resend, such as an order that is no longer relevant for the current market. The interaction with resends is precise and worth understanding. Messages being resent are marked with the `PossDupFlag` in the header set to true, and if a `DoNotSend` exception is thrown with that flag true, a sequence reset is sent in place of the message, while with the flag false the message is simply not sent. Both `toAdmin` and `toApp` are also where you can mutate the outgoing `quickfix.Message`, since it is mutable, and add fields before it goes out. That mutability is a documented feature rather than an accident, and it is how session-level fields get attached.

Questions, issues and security handling

The support routes are split by purpose, which is a good sign for a project of this age. For asking questions you use the mailing list or ask on Stack Overflow with the quickfixj tag. For bugs, the GitHub issue tracker is the place. For security, the project says it welcomes and appreciates responsible disclosure and that contributors are given appropriate credit in the release notes and git logs. The contact for security issues in QuickFIX/J itself is the project maintainer, and the guidance is to contact the relevant project team for issues in libraries QuickFIX/J uses, with Apache MINA named as an example, and then to follow up with the maintainer if a library issue looks particularly exploitable via QuickFIX/J so the upgrade can happen in a timely fashion. Once a security issue is fixed, the communication goes out through the user mailing list and other appropriate channels. There is a `SECURITY.md` at the repository root and an `AGENTS.md` alongside it, plus a separate GitHub Actions workflow for CodeQL analysis.

Examples, and the wider ecosystem

QuickFIX/J includes example applications in the `quickfixj-examples` module, and the documentation points at a short list of related projects. There are examples by Geoffrey Gershaw, examples from the QuickFIX/J Spring Boot Starter, AssertJ assertions for QuickFIX/J, and FixMock, a WireMock-inspired mocking library for FIX. That last one deserves a note, because a FIX integration test normally needs a counterparty to talk to, and a mocking library that speaks the protocol is what makes such a test possible without one. The list is a wiki-style collection and the invitation is open, since you can open a pull request with changes if you would like to be added. The project also has a `quickfixj-orchestration` module, and the presence of the examples module alongside the perf and stress test modules suggests the project treats demonstration and load as first-class concerns rather than afterthoughts.

Editorial conclusion

Adopt QuickFIX/J if you are writing a Java service that has to speak FIX to a counterparty and want the protocol handling, session recovery and dictionary management handled for you. Skip it if your counterpart offers a simpler modern API, since FIX is verbose and a REST or gRPC integration may be all that is required. Before you start, note that a FIX session needs a transport, a dictionary and a configuration file, and that the project ships example applications in the quickfixj-examples module that are a better starting point than a blank project.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. quickfix-j/quickfixj on GitHub
4. README
5. Releases