WxJava: six modules, a BOM since 4.8.3.B, and a JDK floor stated in a note

Six modules, one table, and a note that says which surface is not covered

The module table is the shortest path to understanding the project, because it maps a business scenario to an artifact identifier in one row each.

Official account development takes the MP module. Mini program development takes the MiniApp module. Payments take Pay. Enterprise messaging takes CP. The open platform's third-party platform takes Open. Channels and the online store take Channel.

Then the note under the table is the sentence that saves you a wasted afternoon. Mobile-side capabilities on iOS and Android, such as WeChat login and sharing, still require integrating the official WeChat client SDK, because this project is a server-side SDK.

So the boundary is clean and worth stating plainly: WeChat has many surfaces, this repository covers the back-end ones, and anything that happens on a phone is somebody else's SDK. That is not a gap in the project so much as a division of labour, and a table plus that note is more than most SDK readmes give you before you write the first line of configuration.

The BOM exists to stop you from pinning six versions by hand

There are two documented ways to depend on this SDK, and the recommended one is the newer.

The first is a bill of materials, and the readme is specific about when it became available: it is provided from version 4.8.3.B onwards, and you should use that version or higher. You declare a property holding the version, import the bill as a managed dependency of type pom with import scope, and then declare the modules you actually want with no version at all, because the bill supplies it.

The second is direct: one dependency block with a group identifier, the artifact identifier for your module, and a version. Six artifact identifiers are listed for that form, one per module.

The reason the bill exists is visible in the structure. Six independently versioned modules that must interoperate, because a payment callback and an account lookup will be in the same application, is exactly the case where hand-pinned versions drift. The readme recommends the bill for anyone using more than one module, which is nearly everyone.

The dependency management block you import is short:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.github.binarywang</groupId>
      <artifactId>wx-java-bom</artifactId>
      <version>${wx-java.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

One detail to note: the readme says the latest version is on the published versions page, and the examples below that line use a specific release. So treat the numbers in the examples as an illustration and look up the current one.

The minimum JDK is stated in a numbered note, not in a requirement

There is a numbered list of notes, and one of them carries the platform requirement for the whole project.

It says the minimum JDK required by the current version of the SDK is 8, that people on version 7 can use a specified earlier release, that users still on version 6 should refer to a separate project for that purpose, and that anything older they would have to adapt themselves.

What makes this worth writing about is where the information lives. This is a note in a list of housekeeping items, between a sentence about a download site and a sentence about online documentation. There is no requirements table, no enforcement in the build description, and no tooling that would refuse to resolve on an old toolchain. A project that supports a long tail of JDK versions has usually encoded that somewhere machine readable, and this one has not.

The practical consequence is that a build failure on an old JDK will look like a compilation error rather than a resolution error, and the fix, which is an upgrade or a version switch, is in a numbered list rather than in the error message. Pin your toolchain from the note, not from what your IDE suggests.

It is a toolkit with no web implementation, and it says so

One of the numbered notes is aimed at newcomers and is unusually direct. It says this project is only a development toolkit, that no web implementation is provided, that it is recommended to reference the project with Maven or Gradle, and that details can be found in a demo document or in some of the unit test code in the project.

The unit tests are the interesting part of that sentence. A unit test in a module is the smallest complete example of how that module's client is constructed and called, and for an SDK whose surface is a large number of message classes, the tests are a better index than prose would be. It is also an admission that the answer to how do I initialise this is read the tests.

Combined with the module table, this gives a workable first day: find your row, add the artifact, then read the tests in that module until you find a client and a call that resemble what you need.

The other half of the same note is about reporting problems. New feature requests, bugs, and code that broke because an official interface changed all go to the issue tracker, and the note points at the issue page for discussion and tracking. It also flags interface drift by the platform as a known cause of breakage, which is worth remembering when something stops working after a quiet period.

Five agent skills ship in the repository, and they are the documentation

There is a skills directory, and what it contains is a better map of this project than the readme itself.

Five skills are listed, each as its own directory, each entered through a file of a standard name: a module selector, an integration guide, a troubleshooter, an API contribution guide, and an upgrade guide. The readme describes them as covering module selection, integration, troubleshooting, interface contribution and upgrade migration, for users and for contributors.

The installation instructions are agent-shaped, which is the notable part. An agent that supports remote installation can be given a natural language instruction naming a directory. An agent that does not is told to copy the matching directories into whatever location its own documentation specifies. The worked example uses Codex and shows the three commands: clone the repository, create a directory under the agent's home, copy the skill directories into it.

The useful observation is what this implies about the project's own diagnosis of its difficulty. If a module selector is a skill, then choosing between six artifacts is the part users get wrong. If there is an upgrade guide, then crossing a major version is hard enough to need a procedure. Both are admissions, and both are more useful to you than a feature list would be.

The code assumes you know what an annotation processor is

There is a note addressed to people reading the source, and it is the kind of warning that saves an afternoon.

It says the toolkit adds support for a particular annotation-processing library to keep the code simpler, and that if you do not know that library you should learn about it first, with a link to an article explaining it. Since the article is a WeChat link, the expectation is that you are working in that ecosystem already.

That is a reasonable position for a project with this many modules and this much boilerplate to suppress. It is also a coupling: the source is not plain Java, and a reader without that background will find the classes full of generated members they cannot account for. An IDE without the annotation processor installed will show errors that are not errors in the logic.

The rest of the other-notes section is housekeeping with one item worth flagging. It says some documentation may not be up to date, and invites readers to report it or fix it themselves. For a project whose surface is a large generated SDK, a wiki that admits it lags the code is telling you the code is the specification. Which is also the argument for reading the tests.

The repository is mirrored on a second forge, and the readme is a directory of links

Two structural details are worth knowing before you file anything.

First, the project is synchronised across two forges, with both locations listed and a link to a project page on the second one. The default branch is a development branch rather than a stable one, which for a project with a separately published stable version means the branch you land on by cloning is ahead of what the release notes describe.

Second, the readme is doing several jobs at once. It carries badges for a documentation site, a published versions page, a continuous integration service, an editor vendor, a licence, a generated wiki, a discovery directory and a contributor history chart. It has a section soliciting sponsors with two named commercial products. It invites readers to follow a public account to join chat groups, and lists group identifiers for two of them, one of which is marked as full. It asks people to read an article about how to ask questions before opening an issue, and suggests a paste service for long stack traces.

None of that is a criticism; it is what a decade-old project with a large Chinese developer community looks like. But it does mean the readme is a map rather than a manual, and the wiki, the demo document, the unit tests and now the five skills are where the answers are.

Editorial conclusion

Use WxJava if you are building the server side of a WeChat integration and you know which of the six surfaces you need, since the module table maps a business scenario to an artifact for each. Do not reach for it for mobile login or sharing, because the README says those still require the official client SDK, and do not expect a runnable application, because the project states plainly that it is a development toolkit with no web implementation. Before you start: use the BOM rather than pinning each module, since it exists to keep those versions aligned; check the artifact index for the current version rather than the one in the readme, since the notes point at the published versions page; and note that the minimum JDK is stated in a numbered list rather than enforced anywhere in the build, so an old toolchain will fail at compile time rather than at resolution time.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes