win301

这也算是收获了经验，下次可以先确定依赖库是否真的存在，然后在在确认一下依赖库里的方法是不是确实是你需要的，然后在开始设计程序

建议学 kotlin ，这绝对是更好的 Java ，生态系统也没什么毛病，有 spring 官方的支持，完全没有后顾之忧，其他类型的语言写后端，其实就只有 go 和 Java ，Python 用来做后端，我还没有见过（我孤陋寡闻），而 PHP ，都 2024 年了，建议直接 pass 掉（我绝对不是嫌弃 PHP 啊，就仅着当前这就业形式来说）

毕竟是 9 年前的软件了，到今天的操作系统里安装出点问题正常，建议尝试其他更新版本的 jdk ，比如 17 or 21 or 22 均可，毕竟今年是 2024 年了，就算是刚接触 Java 也应该从一个高起点开始接触

曾经开发过一个比较复杂的系统，功能很多，项目组 5 个人，开发了约 1 年时间，最终项目完成后，大概有 800+类文件（我相信很多人看到这个类文件的数量可能都会想着应该将项目模块化拆分，我在这里不做过多讨论，就先假设项目组没有多余时间来做），每次使用 Maven 打包，需要耗时 2 分 20 秒左右，这已经是优化过一轮后的结果，在优化前大约 3 分 40 秒左右，我想着这样可不行，能不能有其他构建工具能提高项目的打包速度呢？以前就看过 Android 的同事在用 gradle 来打包，我想着后端项目理论上也应该可以打包，原理差不多，然后就去官网看了教程，然后开始研究 Maven 项目转换 Gradle ，通过 gradle 提供的命令行工具转换完成后，迫不及待的试试进行打包操作，然后神奇的事情发生了，这个项目打包成 jar 文件只用了 9 秒钟，虽然打包前还需要改一些打包所需要的代码，但最终的代价是值得的，以后所有项目就都用 Gradle 了

@cMoon 你这相当于是面向数据库编程了，这 b 表和 c 表如果以后还会被其他表关联，你打算怎么做？继续通过继承，然后继续 excludeProperty 无关字段？（假设 excludeProperty 能实现你的想法），建议你复习一下或者重新学习一下面向对象编程有五个基本原则。

绝大部分开发者不会用你这个思路来使用 ORM 框架，所以也不会碰到你的问题
说个正常的或者通常情况下使用 ORM 框架的思路
给这 3 个表分别建立 3 个 entity ，3 个 mapper ，然后你再任意 serviceImpl 类里，随意封装数据结构即可
就是有几百个表都有你说的情况，也都按照这个模式来做，这样即便某些表修改了字段增删了字段，在代码层面的改动会非常小，也很容易改

你可能还在学习阶段，所以才会问出这样的问题来，之所以封装一层 Service ，是因为操作 DB 也就是 Mapper 层，还需要做一些额外的工作才能完成的更好，你可以看下 ServiceImpl 这个类里，都干了什么，而且 ServiceImpl 类是通过继承来实现功能的，并不算是严格意义上的一层，只能算增强，如果你不想用，也可以在你自己的实现类里不要继承 ServiceImpl ，值注入 Mapper 就好

hutool 非常好用,别听这些鄙视链的人瞎说，维护非常频繁，看楼上很多人说某些功能 可能有 bug ，这在软件行业多正常的事情啊，强如 spring ，你们自己去 GitHub 上看，有多少人提 Issues ，以及每次发版列出的 releases 的改动有多少 bug 修复，好家伙我都服了，免费用人家的开发成果，结果还跳出来吐槽别人，你们这是什么精神？

@jacketsmith10 那其他人正常吗？当你遭遇诡异时，如果各种尝试无果后，就应该果断选择看看其他人的环境下是否正常，利用排除法来解决问题，如果其他人都正常，那就是你的环境有问题了，可以考虑重新初始化一下各阶段的环境，如果其他人也有问题，那大家一起想办法和你一个人苦思，效率截然不同，而且有很大概率，其他人已经遭遇过这个问题，他只需要花费 2 分钟告诉你怎么解决这个问题。