Hutool 6.0 Upgrade: Package Name Changes, New Features, and Migration Guide

The Hutool utility library, widely used in Java projects, introduced a major breaking change in version 6.0 by moving all packages from cn.hutool.* to org.dromara.hutool.* , causing compilation errors for existing codebases.

The rename was driven by the library's inclusion in the Dromara open‑source organization, a Chinese counterpart of Apache, which requires the org.dromara namespace for compatibility and branding.

Main changes in 6.0 include:

Package name modification to org.dromara.hutool .

Reorganization of internal utilities into clearer sub‑packages (e.g., org.dromara.hutool.core.text for string utilities).

HTTP module refactor using a façade pattern and SPI to support multiple engines (HttpClient5, HttpClient4, OkHttp3, JDK client).

Performance optimizations and removal of redundant code.

Unified factory methods, replacing createXXX , newXXX , ofXXX with a consistent of style.

Specific API differences are illustrated with before‑and‑after code snippets, such as:

cn.hutool.core.util.StrUtil.isEmpty("admin");

becoming

org.dromara.hutool.core.text.StrUtil.isEmpty("admin");

Other notable changes include updated imports for NumberUtil , ArrayUtil , ObjectUtil , and the migration of classes like ReUtil to org.dromara.hutool.core.regex.PatternPool . The HTTP utilities now use org.dromara.hutool.http.HttpUtil.get(...) with configurable client engines.

For developers, the article suggests three migration strategies:

Heavy dependency projects : stay on 5.x, as the author will continue maintenance.

Light dependency projects : perform a global package rename using IDE refactoring tools.

New projects : evaluate whether Hutool is needed at all, considering native JDK 17 features or building custom utility classes.

Overall, the guide helps developers understand the rationale behind the package change, navigate the new API landscape, and choose an appropriate upgrade path.