Java应用中Constants.java膨胀问题：如何借助第三方库缩减？为何Java无内置通用常量？

Are there third-party libraries with pre-built common constants? #

Absolutely—there are several well-maintained libraries that cover the kind of universal constants you’re dealing with (like field names ID, createdDate, date/time formats, system properties, etc.). Here are the most practical options:

• Apache Commons Lang: This is the go-to utility library for basic Java constants. It includes:
  • String constants like StringUtils.EMPTY, StringUtils.SPACE, and StringUtils.LF (line feed)
  • Date/time format constants in DateUtils (e.g., ISO_DATE_FORMAT, ISO_DATETIME_FORMAT) that align perfectly with your created date/start date use cases
  • System-related constants in SystemUtils (like Java version, OS type) that you’d otherwise define from scratch
• Spring Framework (Spring Data Commons): If you’re working in the Spring ecosystem, this library packs constants tailored for data persistence and common application patterns:
  • Sort direction constants (Sort.Direction.ASC/DESC)
  • Utility constants in org.springframework.util.StringUtils and ObjectUtils that mirror Commons Lang but integrate seamlessly with Spring
• Google Guava: Google’s utility library has its own set of universal constants, including:
  • Strings.EMPTY_STRING and other handy string utilities
  • File system constants in Files (like FILE_SEPARATOR)
  • Immutable collection instances (e.g., Collections.emptyList()) that act like reusable constants for common empty values
• JPA (Java Persistence API): If you’re using ORM, the javax.persistence package includes constants for entity mapping (like TemporalType.DATE/TIMESTAMP and FetchType.LAZY/EAGER) that eliminate the need to define these yourself

Why doesn't Java include these constants natively? #

Great question—this comes down to Java’s core design principles and commitment to flexibility:

1. Minimal core philosophy: The JDK is built to be a lean, foundational platform. It only includes features that are universally required by all Java applications. Constants like createdDate are scenario-specific (tied to business data models) rather than core language needs, so they belong in utility libraries instead of the JDK itself.
2. Ambiguity in "universal": What’s "universal" to one team might not be to another. For example, one team might use "createdDate" (camelCase) while another uses "created_date" (snake_case) or "created_at" (Ruby-style). The JDK can’t enforce a single naming convention without limiting developer flexibility.
3. Faster evolution of third-party libraries: Utility libraries like Commons Lang and Guava evolve much faster than the JDK. They can quickly add new constants or update existing ones based on community feedback, which would be slow and cumbersome for the JDK’s formal release cycle.
4. Avoiding unnecessary bloat: Including every possible common constant in the JDK would bloat its size and force developers to carry around code they don’t need. By leaving this to third-party libraries, you only add dependencies that match your project’s actual requirements.

内容的提问来源于stack exchange，提问作者Smart Developer