这是一个创建于 507 天前的主题，其中的信息可能已经有所发展或是发生改变。
特意单独开贴提问下
只有一个有具体讲到说是 hutool 整个引入太大了
其他几个没有讲到具体理由
是否遇到有什么大坑？
请大家不吝赐教
根据各位回复我需要评估下是否移除 hutool 的引用
只有一个有具体讲到说是 hutool 整个引入太大了
其他几个没有讲到具体理由
是否遇到有什么大坑？
请大家不吝赐教
根据各位回复我需要评估下是否移除 hutool 的引用
 |
101
ZiChun 2023-08-01 15:14:55 +08:00
@runzekk 我一开始就看到了啊。我说的是“线上环境谨慎使用”，你不是觉得我说的不对吗？我问的是你觉得有哪点不对。我自己 87 楼也说了 hutool 好用啊，我从来就没有不建议个人使用 hutool 。
|
 |
102
runzekk 2023-08-01 15:25:35 +08:00
|
 |
103
weijancc 2023-08-01 15:31:53 +08:00
为了某个工具类就引入 hutool, 这玩意太臃肿了, 类名也跟其他常用工具类冲突.
|
|
104
ZiChun 2023-08-01 15:41:05 +08:00
@runzekk 说实话，除了少部分语言例如 Rust 这种国内都不怎么流行的，流行比较久的语言，国内外开发水平基本属于是大差不差。但是国内的确实硬性条件上有个劣势，就是对于这些库的安全测试没有别的知名三方库覆盖全面。
很多安全团队，基本都是逮着那些知名三方库做测试，像 hutool 这种，基本就是靠国人踩坑之后再改。 不是说国产开发者不如国外开发者，这是生态上的问题。就像是操作系统国内一样能开发，但是没有生态支持，始终难以壮大，这个也并非一朝一夕能改善的，我的建议是，个人支持开源，但是涉及到线上，还是尽量少用。 |
 |
105
Qzier 2023-08-01 15:45:05 +08:00
黑马和尚硅谷的讲师喜欢用，估计很多看他们视频的也习惯了用这个库。
|
 |
106
bigbigroll 2023-08-01 16:02:52 +08:00
说 hutool 包大的不如先看看自己公司打的各种 SDK 包叭
|
|
107
runzekk 2023-08-01 16:13:10 +08:00
|
 |
108
chuck1in 2023-08-01 16:20:13 +08:00
|
 |
109
wxlwsy 2023-08-01 16:24:13 +08:00
我看了一遍, 大部分不推荐的人其实就是 hutool 没有按照他们预期执行而已.
人家源码摆在那直接不去看. 出错了就怪人家工具? 长见识了,牛逼! |
 |
110
aino 2023-08-01 17:00:03 +08:00
你们公司打出来的 jar 包多大？
|
 |
111
ciki 2023-08-01 17:04:56 +08:00
主要原因可能只是因为用到的只有 1%，但是却要引入很大的包
|
 |
112
xudaxian520bsz 2023-08-01 17:13:57 +08:00
@aino 都做 java 了，还在乎那边磁盘空间，这比隔壁的 node.js 要好很多，那才是地狱；其次，JDK 9 就提供了模块化系统了，没用过？其实，隔离的 node.js 也有模块化系统；没办法，JavaScript 可没有包的概念。
|
 |
113
QWE321ASD 2023-08-01 17:18:35 +08:00
其实就是触摸到某些人给他家 giegie 站台的敏感点了.说 hutool 有依赖的估计都是纯云,还有聊包体积大小的,不知道的还以为是开发安卓呢.你家服务器差你 2.5mb 空间,没有了直接不转了是吧.黑也黑到点上,hutool 确实出了好几个会导致 oom 的 bug,审核不严一个包下面有的方法抛异常有的抓了风格不统一.有事说事,别和个追星族似的.
|
|
114
aino 2023-08-01 17:56:08 +08:00
@xudaxian520bsz #112 所以我理解不了，他们为什么说 hutool 引入因为 jar 太大。。。。
|
 |
115
SupperCoder 2023-08-01 18:01:48 +08:00
hutool 可以按不同功能引用，虽然我们公司项目是 hutool-all 一把梭 [狗]
|
 |
116
LuckyLight 2023-08-01 19:49:34 +08:00 via iPhone
碰到了不兼容升级
|
 |
117
xuanbg 2023-08-01 21:54:56 +08:00
我说，你们是真的闲！有这个狗功夫，和我一样自己撸一个 utils 不好么？有 bug 自己秒修。
|
 |
118
Bingchunmoli 2023-08-01 23:00:59 +08:00 via Android
@ZiChun springboot 1.3.x 道理是一样的吧，不升级永远都那样
|
|
119
Bingchunmoli 2023-08-01 23:18:48 +08:00 via Android
@zpf124 stringutil 。fastjson 有 spring 有 为什么用其他的，判空看源码都是==null 。isempty 。感觉没什么不同
|
|
120
Bingchunmoli 2023-08-01 23:29:07 +08:00 via Android
@nothingistrue 因为公司要 java
|
 |
121
tohuer00 2023-08-02 00:32:47 +08:00
不是说中国的开源项目就一定比美国的英国的法国的哪国的差。
只是我觉得一个在世界范围流行的东西通常会比只在某个国家内流行的东西靠谱一些。 有些人总喜欢把中国和全世界对立起来，不知道是什么心态。 |
 |
122
Mandyer 2023-08-02 09:05:50 +08:00
@ZiChun #42 哪个公司会立马跟进更新？好多公司还用老的 JDK 呢，做开发不都是秉持稳定无安全问题，不会积极更新，如更新则必然会有各种各样的问题。
|
 |
123
zpf124 2023-08-02 09:10:18 +08:00
@Bingchunmoli
基本上其实都差不多，常用的 isEmpty ，isBlank 就两三行，自己手写也和那几个工具类差不多， 除此之外还有一些方法就是 String 默认方法包了一层空判断，比如 trim ，startWidth 之类的。 我说这个只是类比，剩下的加解密、json 转换、日期转换也是好几个库都有，但选择的时候我还是优先选择了那些知名的、用的人多的。 |
 |
124
cnzjl 2023-08-02 09:17:23 +08:00
|
 |
125
miaotaizi 2023-08-02 09:47:14 +08:00
自己写的时候业务没理清, 怪技术水平?
写什么高科技需要那么高的技术? |
 |
126
heliotrope 2023-08-02 10:06:51 +08:00
我经常用 随便说一个 问题
hutool 的 Cache 回调方法时碰到异常 会自己 Catch 再抛出 RuntimeException 把你自己抛出的自定义异常覆盖掉 导致全局自定义异常捕获失效 开源的不喜欢自己改了就是了呗 我还是倾向于使用 hutool 特别是 http 请求 蛮好用的 没碰到什么大问题 |
 |
127
carytseng 2023-08-02 11:30:17 +08:00
工具而已，到了一定的程度解决问题更重要而不是关注这点小事
|
 |
128
zhady009 2023-08-02 11:36:37 +08:00
1.臃肿很多情况 JDK 的够了也好用，例如日期 文件 IO 相关的只是有很多人不清楚怎么用
2.有些命名很奇怪喜欢各种简写比如 BCUtil 等等.. 3.有些都是做一层装饰套娃本质没做什么，然后换个方法名（怪） |
 |
129
BigBai 2023-08-02 11:56:47 +08:00
小弟我是 ruoyi 和 hutool 都在用,因为公司就我一个 java 开发,项目能跑,下班能早
|
 |
131
nekoneko 2023-08-03 16:01:18 +08:00
|
 |
133
zsdroid 2023-08-04 17:31:27 +08:00
大家来鉴赏下下面这 2 句：
Apache 、Google 、Spring 发布的工具包已经够用了，不需要 hutool 。 Apache 、Google 、Spring 发布的工具包已经够用了，不许用 hutool 。 发现很多人说的是第二种，竟然这么二极管思维。 |
 |
134
chachae 2023-08-06 23:53:41 +08:00
@bigbigroll 哈哈哈哈哈
|
 |
135
shiloh595 283 天前
看到它的测试覆盖率就不敢再用了:(
|
 |
136
Flyfish233 279 天前
用了一个国内开发者写的库，他 fastjson 和 hutool 都 impl 了，导致依赖污染特别严重，自动补全经常跳出来 hutool 的包，我才第一次知道有这东西。又用不到，体积还特别大，后面有更好的库就立马换过去了，真吓人
|
Select Language