Hutool 3.1.1 跨越发布,Java 工具集
路小磊 2017年09月13日

Hutool 3.1.1 跨越发布,Java 工具集

路小磊 路小磊 发布于2017年09月13日 收藏 69

Hutool 是一个Java工具包,提供了丰富的文件、日期、日志、正则、字符串、配置文件等工具方法,并封装了一套简单易用的ORM框架。

主页:http://hutool.cn/

文档:http://hutool.mydoc.io/ (感谢开源中国提供非常好用的Team文档平台)

-----------------------------------------------------------------------------------------------

最近关于Hutool的几件“大事”:

1. Hutool QQ群人数突破500,已升级为千人群,在Gitee中的star数突破2K大关。

2. 结束3.0.X时代,进入3.1.X时代,在广大用户的强烈下期盼,这个版本加入了POI中对Excel读取的支持,考虑到3.1.0可能存在问题(事实上根据热心群友反馈确实存在一些坑木有填),因此与3.1.1一起推送新闻

3. 最重要的,开源中国当家花旦红薯大大强势入驻Hutool群,在此特别鸣谢,哈哈~

4. 随着Hutool知名度的提高,开始有人质疑我抄袭其它开源项目,在这里我想说:请不要质疑,事实上我就是抄了๑乛◡乛๑。我在回复中是这样答复的:

> Hutool的Cache部分借鉴Jodd代码。已在注释中注明。借鉴的同时也在为jodd贡献issue。而很多工具类的方法本身就是通用的,实现大同小异,你会发现Hutool中能看到一些方法与包括Jodd、Guava、Spring、Apache-Commons(例如FastDateFormat类)系列 、Blade(例如FastByteArray类)框架、Nutz框架、t-io、Act-Framework、Cron4j、Jfinal(主要是db模块)类似。作者不否认“抄袭”了一些方法,也不否认很多实现方法来自于网络中的某些博客和Stackoverflow,大部分在注释中都有标注。文档中也有相关说明。作者认为,部分方法借鉴后优化改造并开源符合开源协议要求,也鼓励使用Hutool的任何项目(包括商业项目)在不方便引入Hutool的情况下copy方法到项目中。我想我这种开放态度也会被大部分开源作者和用户理解。

Hutool作为“超级工具类”一直被用户所喜爱,原因之一就是能为用户减少时间成本,降低开发门槛和复杂度,我想做为一个开源项目,它的职责已经达到了。而我,做为一个非程序员,做为一个纯粹的编程爱好者,Hutool于我没有KPI,没有商业,没有金钱,完全是一种心理满足,而这种对于代码的热爱,也会使我持续维护这一项目。

-----------------------------------------------------------------------------------------------

3.1.1

新特性

* ExcelReader中根据单元格格式判断Double还是Long类型(感谢@act家的excel-reader)
* Map相关方法剥离为MapUtil
* 新增CollUtil做为CollectionUtil别名
* 非对称加密加入PublicKey对象和PrivateKey对象构造,RSA加入N,e,d参数支持(感谢@【帝都】小帅帅)
* Props支持其它编码格式(PR#37@Github)
* DateBetween增加可选是否取绝对值选项构造(issue#IETE0@gitee)
* 加入Rythm模板引擎工具类
* cron模块中增加方法支持获取Task和CronPattern(感谢@Γ平淡ㄎ)
* HttpResponse中增加个体Cookie方法
* Hive驱动识别支持。(@【北京】宁静)
* IoUtil中IOException替换为IORuntimeException
* IoUtil和FileUtil增加UTF-8编码重载
* Http增加headerList方法
* Http设置Cookie支持HttpCookie对象列表
* 新增RuntimeUtil,用于执行系统命令的快捷工具类(感谢@【北京】宁静)
* 新增DateUtil.isExpired方法(issue#41@Github)
* 新增MapUtil.join和builder方法(pr#40@Github)

Bug修复

* NumberUtil中针对Double重载方法,避免传入包装类型引起的歧义
* 修复Bean转JSONObject时字段无getter方法导致的字段值丢失问题(感谢@猎隼丶止戈,issue#IEIJG@osc)
* 修复StrUtil.addPrefixIfNot方法问题(感谢@【苏州】咖啡)
* 修复db部分Session中beginTransaction()逻辑问题(感谢@taoguan)
* 修复POI模块ExcelReader空单元格被忽略问题。
* 修复cron模块中移除Task导致的index错误问题(感谢@Γ平淡ㄎ)
* 修复POI模块中自定义单元格含有中文时无法识别为日期的问题(感谢@【昆明】Tang)
* 修复RSA算法编码问题(感谢@【长沙】笑小生)
* Http模块对参数key做编码(issue#IEYLP@gitee)
* 修复ImageUtil写出文件没有关闭流导致的文件被占用问题(issue#44@Github)
-------------------------------------------------------------------------------------------------------------

3.1.0

新特性

* CollectionUtil增加findOne、findOneByField、getFieldValues等方法
* cron模块支持Quartz的"?"表达式
* ReUtil增加getAllGroups方法用于获取所有分组匹配
* CollectionUtil增加toMapList和toListMap方法,提供行列转换(感谢@【北京】宁静)
* WatchMonitor增加文件递归(子目录)监听支持(感谢@t-io)
* cron模块中改进InvokeTask,在初始化时验证并加载类和方法(感谢@【南京】toling)
* 增加ConcurrentHashSet
* HttpRequestsetXXX补充返回this(感谢【南京】peckey)
* Hutool-db增加 BeanHandler、BeanListHandler,find方法增加可变参数(返回字段)
* 增强手机号码验证正则(感谢@【北京】宁静 @【北京】iisimpler)
* 创建Chain接口,用于责任链模式的实现
* JSON.getByExp方法增加重载方法,可以指定返回值类型(感谢【深圳】富)
* FileUtil增加转换文件编码和换行符的方法(感谢@【北京】宁静)
* 增加IterUtil,将CollectionUtil中部分方法迁入

Bug修复

* 修复CollectionUtil中并集、差集问题(issue#IE9VH@osc)
* 修复批量插入只有一个对象无法插入问题(感谢@【北京】游弋苍茫)
* 修复NumberUtil.div错误(感谢@【北京】宁静)
* 修复DateUtil.beginOfYear问题(感谢@【北京】iisimpler)
* 修正Email正则,符合RFC 5322规范(感谢@【北京】iisimpler)
* 修正ArrayUtil.isEmpty逻辑(感谢@【北京】仓山有井名为空)
* 修复计算第几周时没有考虑每周第一天的情况(DateTime增加setFirstDayOfWeek方法),并设置默认值为周一(@【北京】仓山有井名为空)

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:Hutool 3.1.1 跨越发布,Java 工具集
分享
评论(35)
精彩评论
1

引用来自“MrXionGe”的评论

为什么叫跨越发布?
我使用hutool的功能,差不多能有40%,并且完美的避开了上面说的BUG,哈哈哈哈!
因为3.1.0并没有发新闻,所以叫做跨越发布。:stuck_out_tongue_closed_eyes:
1

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情

引用来自“乌龟壳”的评论

POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。

引用来自“罗格林”的评论

如果市面上没有比 POI 质量更好的操作 Office 文档的工具库, 而我自己也没有办法在 JDK 的基础上写一个操作 Office 文档的工具库, 项目又需要操作 Office 文档, POI 就是最好的选择.

引用来自“乌龟壳”的评论

然而我说的是Hutool的定位,不应该融入POI这种东西,并非让人不要用。

如果从真实的项目来说,不少项目用POI是很合适的,毕竟对质量没啥特殊要求,不行了重启就是了,上了集群也不会中断服务。

引用来自“罗格林”的评论

不是很理解你的说法. 既然真实项目可以用 POI, hutool 对 POI 的 API 做一些包装, 提供更轻便的方式给应用使用, 为什么就错误的定位?

引用来自“乌龟壳”的评论

就比如你的框架,让你集成spring-cloud愿意不?原因是有用户说想用spring-cloud里的某个功能。

hutool我个人理解是一个基础类库的性质,补充javase/javaee标准库对高层封装的不足,但始终是一个通用层面的东西,需要良好的质量。

引用来自“罗格林”的评论

我大致理解你的思路了. 不过还是不能赞同.

1. 我有让 Act 去支持 Spring cloud 的打算. 至于怎么做则是另一回事
2. 我认为 POI 作为操作 office 文件的开源产品, 其质量在其所在的领域应该足可以说良好甚至优秀了
我这么比喻吧,你觉得如果有人让你Act集成tensorflow,这是什么层面的不合理?
1
好用,项目中瞬间减少了很多代码,尤其是新人来到动不动要写个功能,通常我都让他先查咱们的文档哈哈哈。。。
1

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。
不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情
最新评论
0
"Hutool于我没有KPI,没有商业,没有金钱,完全是一种心理满足" 点赞!
0

引用来自“MrXionGe”的评论

为什么叫跨越发布?
我使用hutool的功能,差不多能有40%,并且完美的避开了上面说的BUG,哈哈哈哈!

引用来自“路小磊”的评论

因为3.1.0并没有发新闻,所以叫做跨越发布。:stuck_out_tongue_closed_eyes:
哦 以后发布就弄个新闻发布会,开源要玩出排面
0
支持
0
我去。。又看见这俩大神打架了
0

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情

引用来自“乌龟壳”的评论

POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。
哈哈。你们说的都对。我来解释下:Hutool本质上分为两块部分:
1、基础类库部分,主要针对JDK工具化封装主要是Hutool-core模块
2、第三方库工具化封装部分,例如Hutool-poi和Hutool-extra模块,这块主要是其它第三方库的薄封装。
Hutool-all包括了所有这些。
0

引用来自“竹隐江南”的评论

好用,项目中瞬间减少了很多代码,尤其是新人来到动不动要写个功能,通常我都让他先查咱们的文档哈哈哈。。。
:smile: 也欢迎加群使用 “人工” 智能动态API查询功能~~๑乛◡乛๑
0

引用来自“罗格林”的评论

:clap: 支持 #Hutool#: 在前人的基础上为业界的发展做出自己的贡献 :thumbsup:
哈哈,你们俩的讨论已经霸屏啦:stuck_out_tongue:
0

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。
需要说明的是:
1、依赖是可选依赖,Hutool只是提供一种工具化方法简化POI操作。如果用不到Hutool并不会加入任何第三方依赖,同理的工具还有VelocityUtil、RythmUtil、BeetlUtil,针对第三方模板引擎的快捷工具类。
2、工具类的目的是简化开发,并不为JDK的质量负责,也不会为第三方库负责(当然工具类针对一些坑还是会填的),因为假如你不用Hutool也要用POI处理Excel,也要面对这些质量问题,引入Hutool目的本身是简化学习成本,减少踩坑,何乐而不为?
0

引用来自“写给三月”的评论

质量过关发来贺电
这里为啥叫写给三月:flushed:
0

引用来自“李嘉图”的评论

符合国情的jodd,不错
是滴。尤其喜欢jodd的Http客户端和mail模块,真棒。
0

引用来自“smallchill”的评论

哈哈,我发现我的眼光真不错。很多优秀的开源项目刚出来star还没过百我就用了,hutool刚出来的时候bug比较多,所以我把优化过的源码拷到了自己的项目,现在看来可以直接引入jar包了,祝hutool越来越好。
哈哈,谢谢。也欢迎随时提Issue,让Hutool更完美~
1

引用来自“MrXionGe”的评论

为什么叫跨越发布?
我使用hutool的功能,差不多能有40%,并且完美的避开了上面说的BUG,哈哈哈哈!
因为3.1.0并没有发新闻,所以叫做跨越发布。:stuck_out_tongue_closed_eyes:
1

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情

引用来自“乌龟壳”的评论

POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。

引用来自“罗格林”的评论

如果市面上没有比 POI 质量更好的操作 Office 文档的工具库, 而我自己也没有办法在 JDK 的基础上写一个操作 Office 文档的工具库, 项目又需要操作 Office 文档, POI 就是最好的选择.

引用来自“乌龟壳”的评论

然而我说的是Hutool的定位,不应该融入POI这种东西,并非让人不要用。

如果从真实的项目来说,不少项目用POI是很合适的,毕竟对质量没啥特殊要求,不行了重启就是了,上了集群也不会中断服务。

引用来自“罗格林”的评论

不是很理解你的说法. 既然真实项目可以用 POI, hutool 对 POI 的 API 做一些包装, 提供更轻便的方式给应用使用, 为什么就错误的定位?

引用来自“乌龟壳”的评论

就比如你的框架,让你集成spring-cloud愿意不?原因是有用户说想用spring-cloud里的某个功能。

hutool我个人理解是一个基础类库的性质,补充javase/javaee标准库对高层封装的不足,但始终是一个通用层面的东西,需要良好的质量。

引用来自“罗格林”的评论

我大致理解你的思路了. 不过还是不能赞同.

1. 我有让 Act 去支持 Spring cloud 的打算. 至于怎么做则是另一回事
2. 我认为 POI 作为操作 office 文件的开源产品, 其质量在其所在的领域应该足可以说良好甚至优秀了
我这么比喻吧,你觉得如果有人让你Act集成tensorflow,这是什么层面的不合理?
0

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情

引用来自“乌龟壳”的评论

POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。

引用来自“罗格林”的评论

如果市面上没有比 POI 质量更好的操作 Office 文档的工具库, 而我自己也没有办法在 JDK 的基础上写一个操作 Office 文档的工具库, 项目又需要操作 Office 文档, POI 就是最好的选择.

引用来自“乌龟壳”的评论

然而我说的是Hutool的定位,不应该融入POI这种东西,并非让人不要用。

如果从真实的项目来说,不少项目用POI是很合适的,毕竟对质量没啥特殊要求,不行了重启就是了,上了集群也不会中断服务。

引用来自“罗格林”的评论

不是很理解你的说法. 既然真实项目可以用 POI, hutool 对 POI 的 API 做一些包装, 提供更轻便的方式给应用使用, 为什么就错误的定位?

引用来自“乌龟壳”的评论

就比如你的框架,让你集成spring-cloud愿意不?原因是有用户说想用spring-cloud里的某个功能。

hutool我个人理解是一个基础类库的性质,补充javase/javaee标准库对高层封装的不足,但始终是一个通用层面的东西,需要良好的质量。
我大致理解你的思路了. 不过还是不能赞同.

1. 我有让 Act 去支持 Spring cloud 的打算. 至于怎么做则是另一回事
2. 我认为 POI 作为操作 office 文件的开源产品, 其质量在其所在的领域应该足可以说良好甚至优秀了
0

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情

引用来自“乌龟壳”的评论

POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。

引用来自“罗格林”的评论

如果市面上没有比 POI 质量更好的操作 Office 文档的工具库, 而我自己也没有办法在 JDK 的基础上写一个操作 Office 文档的工具库, 项目又需要操作 Office 文档, POI 就是最好的选择.

引用来自“乌龟壳”的评论

然而我说的是Hutool的定位,不应该融入POI这种东西,并非让人不要用。

如果从真实的项目来说,不少项目用POI是很合适的,毕竟对质量没啥特殊要求,不行了重启就是了,上了集群也不会中断服务。

引用来自“罗格林”的评论

不是很理解你的说法. 既然真实项目可以用 POI, hutool 对 POI 的 API 做一些包装, 提供更轻便的方式给应用使用, 为什么就错误的定位?
就比如你的框架,让你集成spring-cloud愿意不?原因是有用户说想用spring-cloud里的某个功能。

hutool我个人理解是一个基础类库的性质,补充javase/javaee标准库对高层封装的不足,但始终是一个通用层面的东西,需要良好的质量。
0

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情

引用来自“乌龟壳”的评论

POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。

引用来自“罗格林”的评论

如果市面上没有比 POI 质量更好的操作 Office 文档的工具库, 而我自己也没有办法在 JDK 的基础上写一个操作 Office 文档的工具库, 项目又需要操作 Office 文档, POI 就是最好的选择.

引用来自“乌龟壳”的评论

然而我说的是Hutool的定位,不应该融入POI这种东西,并非让人不要用。

如果从真实的项目来说,不少项目用POI是很合适的,毕竟对质量没啥特殊要求,不行了重启就是了,上了集群也不会中断服务。
不是很理解你的说法. 既然真实项目可以用 POI, hutool 对 POI 的 API 做一些包装, 提供更轻便的方式给应用使用, 为什么就错误的定位?
0

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情

引用来自“乌龟壳”的评论

POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。

引用来自“罗格林”的评论

如果市面上没有比 POI 质量更好的操作 Office 文档的工具库, 而我自己也没有办法在 JDK 的基础上写一个操作 Office 文档的工具库, 项目又需要操作 Office 文档, POI 就是最好的选择.

然而我说的是Hutool的定位,不应该融入POI这种东西,并非让人不要用。

如果从真实的项目来说,不少项目用POI是很合适的,毕竟对质量没啥特殊要求,不行了重启就是了,上了集群也不会中断服务。
0

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情

引用来自“乌龟壳”的评论

POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。
如果市面上没有比 POI 质量更好的操作 Office 文档的工具库, 而我自己也没有办法在 JDK 的基础上写一个操作 Office 文档的工具库, 项目又需要操作 Office 文档, POI 就是最好的选择.

0
666
0

引用来自“乌龟壳”的评论

这种基础类库应该为质量负责,包括pom.xml

作者敢为 http://git.oschina.net/loolly/hutool/blob/master/hutool-poi/pom.xml 里面的以下【代码】质量负责吗?
<dependency>
  <groupId>org.apache.poi</groupId>
  <artifactId>poi-ooxml</artifactId>
  <version>${poi.version}</version>
  <scope>compile</scope>
  <optional>true</optional>
</dependency>

建议要么全部自己重新造轮子,要么确实对POI代码非常熟悉,敢为他负责(出了问题自己有能力快速修复),否则不建议随便引入第三方的东西。

引用来自“罗格林”的评论

不能赞同这种观点. 现在任何库或者软件都建立在他人的工作基础之上. apache POI 是公认的 Java Office 操作库,引入 POI 没有任何问题. 即便发现 POI 出了问题, 合适的做法是去给 POI 提供 bug 报告, 而不是自己动手去修复.

自己重新造轮子这句话本身也不精确.重新造轮子的边界在哪里? 从 JDK 开始? 还是 JVM 开始? 抑或是从操作系统甚至硬件开始?

我的理解是现在任何人都是生态中的一员,在任何层面上能贡献自己的一点点力量都是值得称赞的事情
POI的质量能和JDK中非图形部分的质量比吗?

你说的大方向没错,分歧点在POI的质量不足以作为基础类库层级使用。
顶部