@CodeCodeStudy WTG 我用来工作 4 年了

ORM 本来就凑合 M 下就行了。完全的 ORM 难用的要死。

@seakingii 用 openjdk 重新编译下项目就行了，有些用了 sun 包的地方改掉就行

我是摆烂了，淘宝买西数紫盘又不是不能用。用个 64G 老 SSD 做加速盘也能凑合玩游戏。

华侨城不是别墅区吗

你先试试写一个提供文件下载接口，随便返回点数据就行。
再写一个用 urllib.request 下载远程文件的用例。
最后把两个方法整合下就行了。

你收到请求后直接改下地址然后 urllib.request 发请求出去就行了啊，把收到的数据直接返回或者临时存盘再返回都行。HTTP 文件下载有几个特殊 Header 表示文件名什么的，你响应的时候填上就行。

做的不错，有版号了吗

@nii 实际就是这个文件管理器好看了点，但并不实用，而且其他地方依然一坨

scala 复杂度感觉跟 c++有的一比

@labulaka521
1.写 SQL 时准确的代码提示，不要把乱七八糟其他表的字段都提示出来（如 DBeaver ）
2.数据预览时能方便的筛选数据，编辑数据，再有自动 ID 的情况下轻松复制行，从 Excel 中复制的多行数据直接黏贴到数据预览界面（如 DBeaver ）
3.方便的表结构编辑，表结构预览，预览时显示注释（如 navicat ）
4.灵活导入 Excel 数据 （如 navicat ）
5.结构同步、数据传输（如 navicat ）

你看这些都做出来要卖多少钱。。
其实 DBeaver 好用的地方很好用，反人类的地方非常反。比如经常看不出我 SQL 执行成功没有。比如表结构编辑非常不简练。导入导出一言难尽。基于 eclipse 构建 eclipse 有的毛病他都有（开销大，卡顿，意义不明地出现 NullPointerException ）

wasm 都快成新一代容器平台了，你说啥玩意不能做

@kran 因为三层架构的设计吧。

Web 开发一开始是一个接口 action 直接发起调用数据库返回数据，这样手动开关事务处理一下就行了，问题就是输入输出都是 Http 请求，在后台没法复用。

为了解决代码复用问题，用了分层架构设计，至少用于处理接口的 action 层与处理数据的业务层会分开。
这样又有了新问题，两个都含有开关事务的业务方法相互调用就会出现问题，这时就需要一个事务管理器进行处理。Spring 就是当时最为简练完善的方案了。

当时还有另一个框架，叫做 ejb ，更加烦死个人，Spring 已经是非常轻量。

@kran 抛开 Java 很多时候过度设计不说。一开始必用 Spring 的原因是依赖注入带来的事务管理器，之后就是 Spring Boot 简化了一堆配置。
现在直接用原生 Servlet 搭个项目是真的要愁死人。

密码只是第一次初始化的时候用的吧。之后都持久化存库了随你改，docker 参数上的密码也就没用了。

lombok 现在都用不动，还说 Kotlin ？

楼上这么多人就没个说增加 jvm 内存容量限制的吗？
jvm 默认给的堆内存大小为物理内存的 1/4 ，所以啥不管直接加物理内存的收益也只有 1/4
启动命令用 -Xmx6g 参数可以分配 6g 内存给堆。
堆内存一般占 jvm 进程内存的大多数但不是 100%，所以最好再开些 swap 避免占满内存。