这是一个创建于 488 天前的主题，其中的信息可能已经有所发展或是发生改变。
特意单独开贴提问下
只有一个有具体讲到说是 hutool 整个引入太大了
其他几个没有讲到具体理由
是否遇到有什么大坑？
请大家不吝赐教
根据各位回复我需要评估下是否移除 hutool 的引用
只有一个有具体讲到说是 hutool 整个引入太大了
其他几个没有讲到具体理由
是否遇到有什么大坑？
请大家不吝赐教
根据各位回复我需要评估下是否移除 hutool 的引用
 |
1
zjp 2023-08-01 01:11:03 +08:00
不喜欢的原因：团队里总有人一股脑把 hutool-all 引进来
不需要的原因：Apche commons 、Google Guava 和 Spring Utils 足够了，代码质量也更高 之前对比过 hutool 和 Spring 查找 Class 的方法，Spring 覆盖的情况更全。明天开电脑看能不能找到详细的 |
 |
2
jdOY 2023-08-01 01:19:33 +08:00  4
1.领导不让用或者领导不喜欢就不用
2.自己觉得 hutool 不好不如考虑下加入开源一起维护 3.团队有人乱引用 hutool-all 那应该是用规章制度去规范，不能怪工具吧？ |
 |
3
echo1937 2023-08-01 08:02:48 +08:00 via iPhone
主要是 Apche commons 、Google Guava 功能已经基本满足了，这两个历史悠久（已经学过了，不用再付出学习成本，基本掌握了最佳实践），社区支持和代码质量经过更长的检验，所以我不推荐混用，但是不反对互相替换，统一规定就好。
|
 |
4
liy333 2023-08-01 08:08:13 +08:00 via iPhone 17
在生产环境引进一个新的依赖库，需要考虑多个方面，比如社区活跃程度，代码质量，维护团队水平……像楼上说的，可以跟 Apche commons 、Google Guava 、Spring Utils 对比下。良好的社区氛围对于一个开源项目也很重要，至少没见过上面几个项目的社区会说出“觉得不好不如考虑下加入”这种 PUA 的话术
|
 |
5
GTim 2023-08-01 08:13:32 +08:00
引入一个超级大的包，就为了使用哪几个方法
|
 |
6
potatowish 2023-08-01 08:29:07 +08:00 via iPhone 1
禁止引入 hutool ，还有小众开发者发布的依赖包。Apache 、Google 、Spring 发布的工具包已经够用了，倒是公司的外包特别喜欢一股脑引入 hutool-all 这类的包。
|
 |
7
mineralsalt 2023-08-01 08:51:33 +08:00 1
我就喜欢 hutool, 各种工具都有, 省心, 包能大多少
|
 |
8
RedBeanIce 2023-08-01 09:01:19 +08:00
正方：省心什么都有
反方：代码行数越多，BUG 越多 |
 |
9
me1onsoda 2023-08-01 09:01:59 +08:00 28
都干 Java 了，包大点有关系吗
|
 |
10
sleepybear1113 2023-08-01 09:12:22 +08:00
Hutool 的 FileUtil 不建议使用。是针对 classpath 为基准的，如果走相对路径，比如 FileUtil.getPath("data/sqlite.db") 那么会在前面拼 classpath 路径，比如会有 xxxxx/target/class/data/sqlite.db ，而不是 xxxxx/data/sqlite.db ，其中 FileUtil.getPath 可能不一定有这个方法，因为很久不用了，为了举例所写的不知道是否存在的方法。
|
 |
11
cnzjl 2023-08-01 09:15:52 +08:00 1
想到了之前不让用若依 ruoyi 的人，有个老哥单独开了个贴，列出了项目的问题
|
 |
12
Bingchunmoli 2023-08-01 09:16:15 +08:00 via Android 1
00 后表示通常用 hutool ，common 和 guava 不熟，⁽⁽◝( •௰• )◜⁾⁾
|
 |
14
sumarker 2023-08-01 09:20:11 +08:00
看个人诉求吧
我觉得完全可以用 作为一个工具包全面肯定会有一个代价就是容易冗余 其他的包冲突 漏洞啥的 , 修修补补也没什么 |
 |
15
litchinn 2023-08-01 09:23:11 +08:00 2
以 hutool 的活跃度来说，有什么坑也早就暴露出来被修复了
所以使用上肯定是没有问题的 问题在于： 1. 没有大厂背书，维护者水平良莠不齐，代码质量对比 guava 肯定是不够的，因此会让人担心未来会暴雷 2. 使用 all 包引入了很多不需要的内容，但是这对 java 用户特别是 spring 用户来说根本不算什么 推荐使用的理由是，足够全面，特别是在团队内有新手的情况下，遇到过很多新手也包括自己在新手时有一个毛病，在网上找代码然后复制到项目中，然后发现有类需要引入依赖，就直接在 maven 中引入了，最后导致一个项目最后把市面上几乎所有的工具类包都引进来，而明确指出工具类使用哪一个包有利于改善这一现象 |
|
16
zjp 2023-08-01 09:23:44 +08:00 via Android
#1 是查找 Method 的方法，对于以下的类
public class Stub { public void a(Object o) {} public void a(String o) {} } 用 cn.hutool.core.util.ReflectUtil.getMethod(Stub.class, "a", String.class) 找到哪个方法只取决于上面方法定义的声明顺序 而 org.springframework.util.ReflectionUtils#findMethod 不会考虑参数的继承关系，只精确匹配 我觉得 Spring 的行为更合理，hutool 即使确实需要支持参数传递子类，也应该找到继承关系最接近的（就像 JVM 那样） |
 |
17
wxw752 2023-08-01 09:25:24 +08:00
没事，等 35 被退休就不用考虑这个问题了😁
|
 |
18
wangYQ 2023-08-01 09:32:09 +08:00
我这做框架的人不喜欢，但是我需要其中一部分功能，我让他去实现，但是现实的不符合需求，最后也得让我引入，但是引也不能全引入，用哪个模块引哪个。
|
 |
19
zzNaLOGIC 2023-08-01 09:36:00 +08:00 6
一个问题，你们项目包大是因为 hutool 么。
|
 |
20
Plutooo 2023-08-01 09:38:19 +08:00
hutool 里面有个 StrUtil ，组内同事因为 veracode 扫描的原因升级了一下 hutool 的版本，代码中有使用到 StrUtil.split ，升级版本后编译不报错但是运行直接报错了。还有很多方法升级版本后编译都没法通过，排查着累后面一把梭换成了 Apache 的 StringUtils 了。国产开源总给我一种感觉，升级版本之后原先的能有一大堆不兼容的，不知道是不是我的错觉
|
 |
21
moreant 2023-08-01 09:40:11 +08:00
hutool 处理 issues 还是挺积极的，并且不熟 Apche commons 、Google Guava 。中文文档、注释、issues 对于英语不好的朋友也比较友好。如果是我自己的开源项目我不会引入，但是公司的项目，早点干完活下班不好吗。
|
 |
22
itechnology 2023-08-01 09:42:19 +08:00 1
这也能怪到国产开源？这不是你同事升级 hutool 版本的锅吗？就算你用 Apache 的 StringUtils 也会存在类似的问题啊。
|
 |
23
jomalonejia 2023-08-01 09:43:52 +08:00 1
没看到有啥实质性的回答
|
|
24
itechnology 2023-08-01 09:44:48 +08:00 2
我感觉对于有些人来说，用国外开源的东西是“技术”正确，用国内开源就是错的，就该被喷……
|
 |
25
keyrinrin 2023-08-01 09:47:04 +08:00 2
看完各位大佬的评论，终于可以安心用 hutool 了
|
 |
26
key0323 2023-08-01 09:50:21 +08:00
hutool 解决的问题:1.最大限度的避免“复制粘贴”代码(官方宣传) 2.同时使用多家公司 api 风格不同带来的学习成本(个人体会)。
|
 |
27
lawsiki 2023-08-01 09:51:18 +08:00
个人感觉挺好用的，再说 Java 又不差那几 M 的大小，再再说，都职业危机了还在乎这个？😂
|
 |
28
tanoak 2023-08-01 09:51:19 +08:00
项目管理问题赖 jar?
|
|
29
key0323 2023-08-01 09:51:57 +08:00
至于楼上说的什么包大的问题把 maven 学会我想可以解决
|
|
30
Plutooo 2023-08-01 09:54:29 +08:00
@itechnology 升级版本后同一个方法编译通过了执行报错，其他框架也会存在大多这种问题吗？那么请教一下升级依赖的正确姿势是什么
|
 |
31
ZiChun 2023-08-01 09:54:43 +08:00
hutool 在某些版本的 json 工具有较大的性能问题，我司踩过坑。
|
 |
32
likeme 2023-08-01 09:56:26 +08:00
认真的？我看了下 hutool-all-5.7.22.jar 才 2.2MB ，大吗？
|
 |
33
28Sv0ngQfIE7Yloe 2023-08-01 10:02:07 +08:00
楼上一些发言能看出工具类鄙视链的味道了
|
 |
34
dif 2023-08-01 10:05:15 +08:00
对我来说，能解决我的问题还不带来风险那就没问题。因为日常已经引用了 apache 的一些工具类，已经能满足绝大部分需求了，对于一些使用量不多的工具类，我选择只引用这一块代码。
|
 |
35
wuzhewuyou 2023-08-01 10:06:50 +08:00 via Android
该用还得用，有些一次性的项目怎么快怎么来
|
|
38
itechnology 2023-08-01 10:08:48 +08:00
@Plutooo 升级依赖之前要项目组要一起评估，一般没有什么特别的必要，是不升级的；升级之后还要进行全面测试，难道你们直接升级，然后就不管了，等出现问题再说？
|
 |
39
leetom 2023-08-01 10:09:12 +08:00
MyBatis-Plus 你们会建议用吗？
或者说会真的在生产环境用吗？ |
|
40
itechnology 2023-08-01 10:11:57 +08:00
@leetom 会用啊，我现在的公司就在用，用了四五年了，没啥问题。上一家公司也在用。
|
 |
41
superchijinpeng 2023-08-01 10:15:38 +08:00
2023 年了，用 kt 吧
|
|
42
ZiChun 2023-08-01 10:18:23 +08:00 2
我上面说的我司踩过的坑
https://github.com/dromara/hutool/issues/2812 参考这个问题。 开源不是不能用，但是用了我相信绝大部分人不会每次都跟进最新版本的变化，修复了什么漏洞。 在这种情况下，生产环境我个人是不建议使用的。 |
 |
43
ily433664 2023-08-01 10:19:25 +08:00 3
说一些我使用中的问题
1 、json 序列化日期格式，每次还要手动指定格式 2 、DateUtil 很多操作返回的是工具定义的 DateTime 类型 3 、http 请求的 url 参数，如果只有参数名没有参数值，会被直接忽略 4 、HttpUtil 会复用连接和 cookie ，导致生产环境出现过 bug |
 |
44
zpf124 2023-08-01 10:31:13 +08:00 2
我可以决定的项目里我会禁止引用 hutool 或者只引入核心，因为 uuid 和雪花 id 确实省得自己写了。
不想引入的原因很简单，同样一个 StringUtil ，存在以下选项的时候 spring,commons-lang3, guava ，commons-lang ，hutool 的时候我选择大厂背书或者社区核心维护的库优先于 小众群体维护的库不是很容易理解吗。 写代码连尽量不堆屎山的追求都没有，心态就是混口饭吃，那你不论干哪行都是咸鱼，当然了，当一天和尚撞一天钟的人也许才是大多数。 至于公司项目，不归我做主，我也没必要非当事逼逼着同事改代码，那爱咋样咋样，领导有追求我跟着干，大家都无所谓我也不逆势而为。 所以公司项目引入乱七八糟，上面那几个同功能的库都有，有的甚至会由于依赖导致重复引入了同一个库的不同版本，那就引呗，再加上有些同事自己攒了多年自己写的工具类，以及接入某写 SDK ，人家示例代码里的 util ，五彩缤纷。 |
 |
45
ttthys 2023-08-01 10:33:43 +08:00
都干 Java 了还考虑包大不大的问题么，嫌包大的话直接 maven 打包的时候忽略第三方包不就好了，我想用 hutool 的大部分都是看有中文注释，功能比较全面才选用的吧
|
|
46
ZiChun 2023-08-01 10:34:20 +08:00 2
说一个很多人都没提到的点吧：
比较知名的开源库一旦出问题，你获取这个问题的信息渠道会比用国内的开源库广很多。 例如 log4j 一出问题，业内铺天盖地都是转发，绝大部分时候都能在线上出问题之前进行升级。 国内的一些开源库如果存在某些漏洞，基本只会在你自己的产品线上出问题了，你才可能搜到，这也是为什么不推荐在线上环境使用的原因。 如果要用，就要自己做好对该库的信息跟踪，如果引入一次 maven 就不管了，那只会变成屎山里的一坨。 |
 |
47
lmq2582609 2023-08-01 10:38:38 +08:00
hutool 非常好用
|
 |
48
sppan 2023-08-01 10:39:09 +08:00
遇到过的坑包括但不仅限于如下：
|
 |
49
manhere 2023-08-01 10:39:15 +08:00
NIH 综合症
|
 |
50
Nich0la5 2023-08-01 10:40:04 +08:00 1
我司禁用的理由是代码质量良莠不齐很难保证，本人没读过源码不清楚是不是事实
|
|
51
sppan 2023-08-01 10:41:19 +08:00 1
@sppan 1 、文件工具判断是否存在，在某个场景下会自动创建父级文件夹。
2 、md5 工具获取大文件 md5 性能接近于不可用。 3 、http 工具请求包数据有问题，忘了从哪个版本开始的了，我记得我提过 issue ，但是似乎没查到问题在哪。 |
 |
52
LeegoYih 2023-08-01 10:44:10 +08:00
hutool 的问题：代码质量参差不齐； Coverage 太低；间接依赖与项目中的依赖存在冲突，主要是 Spring 相关的。
有其他高质量的依赖库可选，公司这么多年自己沉淀了很多工具包，如果是因为懒而直接引入一个 hutool-all ，那么是团队有问题。 |
 |
53
xiaoshiguang9 2023-08-01 10:51:31 +08:00
@cnzjl 若依问题贴怎么搜啊
|
 |
54
missya 2023-08-01 10:55:55 +08:00
国内开发✗
国外开发✓ |
 |
55
ldlood 2023-08-01 10:59:01 +08:00
用这些工具，还特么鄙视这个工具鄙视那个工具，来找那微弱的优越感？
你有这能力，为什么不自己去写 Utils 啊 |
|
56
Plutooo 2023-08-01 11:09:00 +08:00
@itechnology 第一个问题是硬性要求，第二个问题不就是出现的问题吗，我也没说是线上报错吧，编译不报错运行报错你不觉得是一个徒增成本的问题？
|
 |
57
runzekk 2023-08-01 11:09:42 +08:00
@liy333 啧啧，这种话都不能说了么，都是程序员，不参与国产开源贡献，反而自己还踩一脚、唾两口。
你真的看过 Apche commons 、Google Guava 、Spring Utils 社区么？你贡献过么？你没有深度参与过，你怎么评价的？ 先说一些名词，方面，丝毫没有落地的对比，然后再说一些让你加入优化是 pua 的武断恶意观点。你真是国产开源的阻力。 |
 |
58
cslive 2023-08-01 11:11:18 +08:00
spring 项目 ，apache 包都已经引入了，再引入 hutool 没必要
|
 |
59
yule111222 2023-08-01 11:25:03 +08:00
用 Kotlin 吧，utils 本质上就不 OOP
|
|
60
zpf124 2023-08-01 11:39:51 +08:00
@runzekk 凭什么不能说，好与不好不是有客观事实评价标准的吗？
我说 apache commons 不好的时候我也得加入才行？ 我说 apache BeanUtils 的 copy 性能特别差是不是得先给他们提 issue 才行？ |
 |
62
coala 2023-08-01 12:09:39 +08:00
算是问了我也想问的问题， 看了一圈我还是继续用吧。
hutool 大概是去年吧， 我当时用 JDK11 ， 发现支持不是特别好，刚去看了下已经说支持 JDK8+了。 还有就是 JSON 类的不是特别符合 Spring 那套规范吧， 序列化之类的我之前遇到不少问题。 很多小功能真的蛮方便。 |
 |
63
adoal 2023-08-01 12:10:23 +08:00 1
不懂 Java 开发，从一个客户方的角度看，遇到的热衷使用 hutool 的开发方，开发能力和工程实施能力较为欠缺，技术水平令我无奈。
当然我知道这两件事在逻辑上既没有正向因果关系也没有反向因果关系。但就我遇到的小范围样本而言，有相关性。 |
 |
64
tairan2006 2023-08-01 12:18:27 +08:00
我只用了 hutool-core ，主要补一些缺失的工具类。guava 和 apache-common 也经常用，反正混着来。
|
 |
65
ZeroDu 2023-08-01 12:33:24 +08:00
 楼里有些人真的是，舔呀； hutool 还是不错的；谈代码质量，我看国内那些大厂开源也不见得多好吧，bug 不也很多。闲包大这个更是无从说起 |
|
67
jdOY 2023-08-01 12:35:21 +08:00
|
 |
68
nothingistrue 2023-08-01 12:42:38 +08:00
粗略扫了一下 hutool 的宣传理念和 hutool 的子项目分派，这玩意不是 Apche commons 、Google Guava 这样的基础工具包（或者更确切的说，JDK 扩展包），也不是 okhttp 、jackson 、netty 这样的专业领域工具包，而是像一个封装了 okhttp 、jackson 、netty 等各种工具的脚手架框架。
这玩意，用得人肯定不会少，但是你要去找推荐就基本不会有人推荐——要想用脚手架模式开发，为啥不用 PHP 呢。 |
|
69
zpf124 2023-08-01 12:44:12 +08:00 7
@adoal
其实是有关的，热衷于 hutool ，ruoyi ，mysql-plus 的大多数真的只是糊裱匠，“我只管最快速的干出来, 不出 bug 不就可以，工作而已何必较真” 就像做饭，有些人也推荐预制菜，买个半成品回家，这边一热那边撕开调料包倒进了不就好了，像方便面一样，犯得自己搞么，择菜洗菜自己弄半天还不如人家调料包香。 你说预制菜做的不好吗，其实 有一些真做的不错的，而且对于水平差的人，预制菜真的做出来的水平真的比它自己重头做好非常多。 但我不喜欢预制菜的统一口味调味料, 我觉得煎炸炒用同样的料包做出了的味道虽然也都好吃，但比不上我煎的时候配煎的料，炒的时候配炒的料做出来的香。 |
 |
70
easylee 2023-08-01 12:46:47 +08:00
个人认为是一个不错的框架，提过几次 pr 和 issue 处理非常快。
好与不好，取决于使用者实质性使用行为。 |
|
71
potatowish 2023-08-01 12:47:25 +08:00 via iPhone
hutool 这种大而全的工具就适合快速开发上线的项目，没那么多讲究，功能开发出来就行。
|
 |
72
jeesk 2023-08-01 12:59:48 +08:00
国产是原罪。
|
|
73
zpf124 2023-08-01 13:04:30 +08:00 4
@jdOY 如果你简单了解过相关工具的对比文章就会知道，apache commons 的 BeanCopy 效率差是大家都知道的事实，说这个事实就是为了告诫其他人在新项目里少用，而不是为了逼社区改。
人家不改是有充分的理由，就是为了兼容，为保证之前的使用者不会在更新后就出现不一致的行为。 你提 issue 也只会被人家指向最初那个不予修复的回答。 最后，使用和谈论本身就是一种促进社区活跃的行为。 如果你们的思想是 “用你们开源就是欠你们的，就是白嫖，就没资格评价这个开源东西好坏”，那建议你们别开源。 linus “fuck nvidia” 的时候也没给他们提 issue 更没有给他们写代码推 pr 。 |
 |
74
WesleyWong 2023-08-01 13:04:46 +08:00
我就用 hutool-core 挺不错的。
|
|
75
runzekk 2023-08-01 13:07:13 +08:00 1
@zpf124 问题是你说客观事实了么？有分析么？有指标么？毫无理由的指责就是骂人。
你从哪里推出来的类比？我说不能说是指的 ‘自己觉得 hutool 不好不如考虑下加入开源一起维护‘，这句话，我认为这句话说的没错。 宁愿卑微如蝼蚁不要扭曲如蛆虫。 你不去给开源软件贡献，还在这无端指责，说你是开源软件的阻力，有错么？ 还有我没艾特你把，你想插话就往上看看发言再说话，不然我都懒得理你。 |
|
76
runzekk 2023-08-01 13:10:35 +08:00
最可悲的是什么，没有想让其变好的想法，更不付诸实践，反而唾一口踩一脚，高高的往下俯视。
你配吗？ |
|
77
zpf124 2023-08-01 13:15:30 +08:00
@runzekk
“你不去给开源软件贡献，还在这无端指责，说你是开源软件的阻力，有错么？” 哇，那你们不应该做开源啊，你们应该去找人抱团做饭圈啊。 我说 spring 太臃肿的时候，我也拿不出证据了，毕竟我太主观了是吧， 我原来是开源的阻力了。 我说 apache commons 的 Bean copy 性能太差，还没给他们贡献过代码，那我是不是就应该是 Java 社区的罪人了。 另外建议你们别用现有的开源协议，你们得自己写一个 license 把你们的诉求也写进去，毕竟这些协议 “居然没有禁止别人在不提交代码的情况下评头论足，开源协议里就应该把这些阻碍社区发展的白嫖怪轰出去” |
|
78
runzekk 2023-08-01 13:16:35 +08:00 2
作为一个 mybatis 和 seata 的贡献者，我说两点客观的评价。
1. hutool 是不错的，无所不包，用什么方法，用什么工具类，什么场景都能覆盖到。很多国外的开源脚手架，获取的结果往往还要自己转一下。 2. hutool 没有国内外的差别，比如时区问题。我之前写代码获取时间的时候，没注意使用到了 spring 中的一个时间类，是外国时间和国内时区不一样，导致一个 bug 。因为我觉得只是获取一下时间比较简单所以没测试。后来用国外的一定测一下。 3 。 抽象一点从设计层面来说，hutool 缺乏一些设计感，源代码比较冗余不够简洁，但是功能没问题。定位是一个工具类，从定位来看我觉得没啥大问题。工具类就是工具类，你不能指望他像 seata 和 mybatis 一样抽出来一个模型，然后围绕模型来迭代增加代码。 4. 还有说社区没有外国工具类火热的我就想笑，你但凡点开 github 看看社区都说不出来这种话。 |
 |
80
Vegetable 2023-08-01 13:18:41 +08:00
我很难接受为了做一次 md5 就专门引入一个新的依赖的行为。
|
|
81
zpf124 2023-08-01 13:19:40 +08:00 1
|
 |
83
newaccount 2023-08-01 13:29:39 +08:00
spring-boot-dependencies 有定义的，无脑用，升级有保证
没有的，鬼知道哪次升级就跪了 |
 |
84
win301 2023-08-01 13:30:40 +08:00
hutool 非常好用,别听这些鄙视链的人瞎说，维护非常频繁，看楼上很多人说某些功能 可能有 bug ，这在软件行业多正常的事情啊，强如 spring ，你们自己去 GitHub 上看，有多少人提 Issues ，以及每次发版列出的 releases 的改动有多少 bug 修复，好家伙我都服了，免费用人家的开发成果，结果还跳出来吐槽别人，你们这是什么精神？
|
 |
85
easymbol 2023-08-01 13:35:36 +08:00
不管黑猫白猫，能够让我摸鱼的猫就是好猫
|
|
87
ZiChun 2023-08-01 13:51:21 +08:00
@runzekk 你的观点有一个误区。对国内开源的支持是没问题的，生产环境尽量谨慎使用开源库也是没有问题的，这两者本身就可以是不同场景。
生产环境比起对开源的支持，首先是要对公司负责，就像我楼上提到的例子，hutool 某些版本确实存在一些可能导致线上服务器问题的 bug 。这种时候，“自己觉得 hutool 不好不如考虑下加入开源一起维护”这个观点完全就属于是本末倒置了，因为你首先要做的是保证线上环境的稳定。（而且也不是说不能用 hutool ，是指要用的话，就要定期检查是否存在重大漏洞修复） 对待这个问题不能二极管，hutool 确实能够给开发带来便利，但是这并不影响在没有严格的三方库风险控制的情况下，尽量别用 hutool 上正式环境。如果是个人项目，怎么用都行。这本来就不是一个 hutool 到底好不好用的问题，而是一个在生产环境引用是否具有潜在风险的问题。单纯说好用，我也觉得好用。 |
|
88
liy333 2023-08-01 14:00:06 +08:00 via iPhone
国内的社区，楼上可见一般。论点基本都是：我觉得好用；你用起来不行说明你不会用；屁股大于一切；你行你上；你不上就不要逼逼
|
|
89
runzekk 2023-08-01 14:00:40 +08:00
@ZiChun 那些问题呀？你倒是举例子呀，别空口造谣侮人清白。
对 xxx 负责就是要多测试，h 你是什么大公司么，开源漏洞还能影响到你。起码我司千万以上用户，每次开源漏洞就算有，也没被利用过。 你把使用国外开源 = 线上稳定了。 你是怎么推出来的结论。 你还定期检查你给我逗笑了，你开检查开源软件呢。 生产环境关开源吊事，自己水平有限，问题当然多。 |
|
90
ZiChun 2023-08-01 14:06:47 +08:00
@runzekk 1. 42 楼，json 工具类的问题
2. 我没有说国外 = 线上稳定，而是 46 楼的观点，知名三方库的重大漏洞传播更快，在真正出现问题之前修复的可能性显然更大，而 hutool 显然目前还做不到这一点。 关不关开源什么事我不清楚，但是我提到的这个 json 工具问题显然完完全全是 hutool 的 bug ，跟其他开发没关系。 |
|
91
liy333 2023-08-01 14:08:57 +08:00 via iPhone
楼主不妨阅读下这篇文章，自行判断 https://mp.weixin.qq.com/s/QI52VbaQfFOTZyNSfkHk0w
|
 |
92
cqx2005 2023-08-01 14:10:07 +08:00 1
我项目引入了 hutool ，但其代码设计，确实不好，贴代码
/** * 下载文件 * * @param path 文件路径 * @param fileName 文件名 * @param outFile 输出文件或目录 */ public void download(String path, String fileName, File outFile) { if (outFile.isDirectory()) { outFile = new File(outFile, fileName); } if (false == outFile.exists()) { FileUtil.touch(outFile); } try (OutputStream out = FileUtil.getOutputStream(outFile)) { download(path, fileName, out); } catch (IOException e) { throw new FtpException(e); } } /** * Ftp 异常 * * @author xiaoleilu */ public class FtpException extends RuntimeException { private static final long serialVersionUID = -8490149159895201756L; public FtpException(Throwable e) { super(ExceptionUtil.getMessage(e), e); } public FtpException(String message) { super(message); } public FtpException(String messageTemplate, Object... params) { super(StrUtil.format(messageTemplate, params)); } public FtpException(String message, Throwable throwable) { super(message, throwable); } public FtpException(Throwable throwable, String messageTemplate, Object... params) { super(StrUtil.format(messageTemplate, params), throwable); } } download 方法把 IO 异常代替为 RuntimeException 。糟糕的设计。 |
|
93
runzekk 2023-08-01 14:15:20 +08:00
@ZiChun 2. hutool 是工具类库，log4j 是某一个细分领域下面的开源，两者都不是一个性质的东西。除了都是软件。。。真不知道怎么能放一起比较的。
bug 当然有，你搞笑呢，一个 bug 说明了什么呢，spring bug 还少么。你这是杯弓蛇影、因噎废食？还是好不容易找到一个 bug ，我一定要深深深深的记在心里。。。一定每次都拿出来说，一定显摆一下我看了开源软件了，找到了 bug 了。 |
|
94
ZiChun 2023-08-01 14:21:14 +08:00
@runzekk 我不知道你怎么理解为因噎废食的。
线上出问题 -> 找到了 bug -> 评估三方库风险 -> 建议谨慎使用 Spring 的问题是多，但是即使 Spring 这么多问题，我至今没有遇到任何一个导致服务器宕机的问题。 但是 hutool 确实导致线上服务器宕机了。 如果说一个开源库已经导致线上事故了，还要说不使用是因噎废食，那我评价只有一个字：孝 |
 |
95
lyxeno 2023-08-01 14:22:34 +08:00
Hutool 代码和文档质量有好有坏，我个人习惯用 Apache Common ，方法说明全很多，找不到再用 Hutool 的。毕竟 Hutool 里的工具比某些同事连单测都没，不知道哪里拷过来的工具方法强多了。
|
|
98
ZiChun 2023-08-01 15:00:24 +08:00
@runzekk 你不妨说说你的观点，我认为线上环境谨慎使用开源库，你觉得我说的不对，那就是线上应该无脑使用开源库咯？只要是开源，就应该优先考虑？希望你能知道，开源本身并不意味着高人一等，相反，开源一定是相对 unstable 的，你如果真的想讨论，没必要总是在反驳别人，你可以说说你的想法，你要是说的对，也可以说服别人。
|
|
99
28Sv0ngQfIE7Yloe 2023-08-01 15:01:12 +08:00
|
Select Language