相比 JavaScript 社区的 DRY，我可能更喜欢 Java 社区的“RY”

[Cbdy]

[lihongjie0209]

这是 Java 没有模块化的锅。很多时候 public 只是在当前模块内 public， 但是在之前的 Java 中， 这是在整个 JVM 中 public， 所以会导致内部的很多实现类 util 类暴露出去， 后面支持模块化之后可以自己定义需要暴露的类和接口， 会好一点。

同时作为一个第三方包， 应该尽量少的有别的依赖， 比如很多 StringUtil 都是在特定项目中有意义，并不是类似 common 中的一样提供一个通用的 StringUtil， 所以也没必要因为一个工具类引入一个第三方 jar 包。

[pursuer]

当需要造个轮子的时候，搜一下类，说不定轮子都不用造了？哈哈哈。原本的 default 访问级别就是限定同一个包内使用，但是不少项目为了跨包用都直接 public 了。大部分 IDE 都支持正则屏蔽特定包下的自动补全，所以感觉影响也不大

[hronro]

JavaScript 项目通常是对编译后大小敏感的，如果每个第三方包都实现一些对 String 封装的类似逻辑，最后编译出来的整个大小会膨胀很多

[chendy]

也是没办法，总不能到处都是 (str != null && !str.isEmpty())…

[HuHui]

node_module 显然更先进点

[SpencerCJH]

用 common-lang3 的那个（逃