Hutool: a Java utility library you can copy, not just depend on

The gap Hutool fills between the JDK and a framework

Java's standard library gives you the primitives and leaves the conveniences to you. Reading a file into a string, formatting a date, parsing a JSON fragment, or opening a JDBC connection all take more lines than the task deserves. Hutool is a collection of static utility classes that wrap those operations. The README describes it as a set of tools covering strings, numbers, collections, encoding, dates, files, IO, encryption, JDBC, JSON and an HTTP client. The intended user is a Java developer who wants those helpers without adopting Spring, Apache Commons or a heavier framework. The project's own framing is unusually honest about provenance: the README says most utility classes are '搬运' (carried over) and that you can copy and modify them without attribution. That is a statement about how the code is meant to circulate, and it shapes both the licence choice and the support model.

Module layout: hutool-all versus picking one artifact

The README lists twenty modules. hutool-core holds Bean operations, dates and general utilities. Around it sit hutool-aop (JDK dynamic proxy, for aspect support outside an IoC container), hutool-bloomFilter, hutool-cache, hutool-cron (Crontab-style scheduling), hutool-crypto (symmetric, asymmetric and digest algorithms), hutool-db (a JDBC wrapper following the ActiveRecord idea), hutool-dfa (multi-keyword search on a DFA model), hutool-extra (template engines, mail, Servlet, QR codes, Emoji, FTP, word segmentation), hutool-http (an HTTP client built on HttpUrlConnection), hutool-log (a logging facade that detects the implementation), hutool-script, hutool-setting, hutool-system, hutool-json, hutool-captcha, hutool-poi, hutool-socket (NIO and AIO), hutool-jwt and hutool-ai. The README states each module can be pulled in separately, or all of them through hutool-all. That choice matters more than the feature list. A single artifact is convenient in a prototype and awkward in a library you publish, because every transitive dependency of every module becomes your consumers' problem. The README does not enumerate what each module pulls in, so the pom is the place to check.

Getting it into a build: Maven, Gradle and the JDK 8 floor

The README gives the Maven coordinates as groupId cn.hutool, artifactId hutool-all, version 5.8.47, and the Gradle equivalent as implementation 'cn.hutool:hutool-all:5.8.47'. The same version is linked on Maven Central for a direct jar download. The stated baseline is JDK 8 or later. For JDK 7 the README points to Hutool 4.x and notes that line is no longer updated, so a JDK 7 shop is choosing between an unmaintained branch and an upgrade. There is also a note that Android is untested and that not all utility classes or methods are guaranteed to work there; that is a real constraint, not a formality, because reflection-heavy Bean and system utilities are exactly the kind of code that behaves differently on Android. Building from source means downloading the repository from Gitee (either v5-master or v5-dev) and running ./hutool.sh install from the project directory, after which the Maven coordinates resolve locally.

v5-master is frozen, v5-dev is where changes land

The branch table in the README is the most operationally useful part of the document. v5-master is the release branch, matches the jar published to Maven Central, and does not accept pull requests or modifications. v5-dev is the development branch, defaults to the SNAPSHOT version of the next release, and accepts changes and pull requests. The practical consequence: if you fork to fix a bug, a patch against v5-master has nowhere to go. You either target v5-dev or you carry the change yourself. The same table explains why the master branch can look quiet while the project is active. The README asks bug reports to include the JDK version, the Hutool version and the versions of related dependencies, which tells you the maintainers treat version skew as a likely cause. Release history is steady rather than dramatic: 5.8.44 in March 2026, 5.8.46 in May 2026, 5.8.47 in July 2026, with the default branch receiving commits after that. There is no stated long-term support window and no published deprecation policy in the material, so treat the 5.8.x line as a moving target and pin an exact version.

MulanPSL-2.0 and the copy-without-attribution stance

Hutool is licensed under MulanPSL-2.0, and the README links the licence text on the OpenAtom Foundation site. The README's philosophy section goes further than the licence requires: it says you may copy and modify the utility classes without marking anything, and only asks that bugs be reported back. That combination is why Hutool spreads through internal codebases as pasted snippets rather than as a dependency. It is also why the project accumulates utility classes of uneven depth; a library that invites copying has less pressure to keep a stable public API. If you vendor a class into your own source tree, you own it from that moment, including the bug fixes the upstream project ships later. This is a description of the licence and the stated intent, not legal advice; if MulanPSL-2.0 compatibility with your distribution model matters, have someone qualified read the licence text rather than this article.

Where Hutool is the wrong dependency

The HTTP module is the clearest example. It wraps HttpUrlConnection, which the README states plainly. That is fine for a health check or a webhook POST. It is a poor fit for connection pooling, HTTP/2, fine-grained timeouts or interceptors, because HttpUrlConnection does not offer those in a form a wrapper can expose. Teams that reach for hutool-http and later need a pooled client end up rewriting the call sites. The database module carries a similar shape: hutool-db follows the ActiveRecord idea, which means table rows map to objects with attached persistence methods. That is compact for small applications and awkward when you want a repository boundary or explicit transaction control across several aggregates. The Android caveat applies to the whole library rather than one module. And hutool-all as a dependency in a published library is a decision you should make deliberately, since it hands your consumers every module's transitive graph whether they use it or not.

Comparing the approach with Apache Commons and Spring

The nearest well-known alternative for the same job is Apache Commons, split across commons-lang3, commons-io, commons-codec, commons-collections4 and others. The difference in approach is scope and cohesion. Commons libraries are narrow and conservative: each artifact does one thing, changes slowly, and keeps its API stable across major versions. Hutool is broad and opinionated, covering JSON, HTTP, cron, captcha and JWT in one project with a shared naming style, and it evolves faster. If you want a small, stable surface that you rarely think about, Commons is the lower-risk pick. If you want one dependency that answers most small questions without adding four coordinates, Hutool is the lower-friction pick. The trade is that Hutool's breadth means more of your application's behaviour is decided by one project's release cadence. For JSON specifically, Jackson and Gson are the alternatives, and both have larger ecosystems around them than hutool-json; the reason to use hutool-json is consistency with the rest of Hutool, not capability.

Upgrade cost and what to check before you pin a version

Upgrading within 5.8.x looks routine from the release list, but the project offers no compatibility statement in the material, so the safe procedure is to read the release notes for the specific version you are moving to and to run your test suite against it. The bigger cost is the v5-dev branch: if you need a fix that has not been released, you are either building a SNAPSHOT or patching locally, and the README's own branch table says v5-master will not take your change. Budget for that before you file an issue expecting a backport. Two things are worth verifying first. Open the pom of the module you actually intend to use rather than assuming hutool-all's dependency set, and confirm the exact artifact and version on Maven Central instead of trusting a branch name. Hutool's value is that it removes a hundred small decisions from a Java project; the cost is that you are trusting one library's judgement on all of them at once.

Editorial conclusion

Adopt Hutool if you are on JDK 8 or later and want a single dependency for the small tasks that would otherwise be scattered across three or four helper classes. Do not adopt it if you need a supported Android target, or if you want an HTTP client or ORM layer that you can tune per call; the README explicitly says Android is untested and the HTTP module is built on HttpURLConnection. Before committing, open the pom for the specific module you plan to use and check what it drags in, because hutool-all is not the same dependency as hutool-core, and verify the exact version string you pin against Maven Central rather than the branch name.

Official sources

1. chinabugotech/hutool on GitHub
2. License: MulanPSL-2.0
3. Project website
4. README
5. Releases