@Slurp 这次没有提到 「而随着 JDK15 的推出, kotlin 的接口也能被密封了」,看来是承认 kotlin 在密封接口慢半拍 JVM 了.「非要假设别人乱反射你？」是 kotlin 自己 7 年前不做密封接口的理由, 结果成我说的了.

被打脸了还嘴硬, 菜到觉得有 internal 就不用 sealed 了, 还把观点提炼错了

@Slurp 链接贴脸上了还嘴硬

「而随着 JDK15 的推出, kotlin 的接口也能被密封了」下一句就是 「而且 JDK15 以前的运行时也支持这个特性」, 还要我试「 Kotlin 1.7 JDK8 能不能编译密封接口」.下次和别人対线麻烦看全再回.

展开说下关于 kotlin 的 sealed interface
https://www.reddit.com/r/Kotlin/comments/4io0q5/i_can_has_sealed_interface/
7 年前是这么说的

>> Kotlin does not support sealed interfaces because there is no way to prevent Java classes from implementing the same interface. Therefore, it's not possible to obtain the exhaustiveness guarantee that sealed classes provide.

而上面那个链接里面是这样的
2 年前
>> How about using Java 15 sealed interfaces, and limiting the feature only to that Java version or later?
>> There's no reason to limit this feature to Java 15.

我并没有说 kotlin 所做是错的, 恰恰相反: "etbrains 已经做得(当时认为的)最好了". 我很为不妙的地方是, 尽管已经做得最好了, 但还沿用了 5 年的反设计, 为什么

@Slurp
??? 你的攻击性让我放弃和你正常沟通

https://youtrack.jetbrains.com/issue/KT-20423/Support-sealed-interfaces

@FrankHB 没太懂, 想听听你对 kotlin 的想法?

支持 structural type system 是必要不充分条件, 就像 lambda 这个古老概念一样, 以前这个特性是可选的, 而现在是必须的. 比如我们不需要 null, 必须要有泛型, 泛型支持协逆变的最佳实践. 尽管早有有了这样的想法, 但是直到最近(10 年?)才形成共识. 比如说我今天的暴论: undecidable 的类型体操都是错的, 等到 20 年后说不定就是喝水一样平凡的事情.

@tedzhou1221 你应该使用 EnumMap 而不是 HashMap

@Aurt 这个比喻太妙了

语言决定论主张语言决定思考模式, 语言相对论主张语言结构及使用可能影响思考模式及决策方式 -- 无论哪个版本, 至少认为"自然语言"对思考的影响是显著的, 不过对于主张编程语言工具论的 Java 程序员来说, 至少编程语言对他们没啥影响, 毕竟他们写代码从不思考.

言归正传, 私以为 kotlin 是伪装成现代编程语言的 java, 现代编程语言的一个重要特性是支持 structural type system, 否则语法糖会变得特别苦.

举个例子 java 中的 lambda 其实是只有唯一方法的接口的匿名实现, 而 kotlin 中, 看起来我们可以定义 T -> R, 但实际上它和 java 没啥区别, kotlin 的标准库里面绝望地定义了 Function0 到 Funciton22 以及 FunctionN 合计 24 个 class;
```
var lambda : () -> Unit = ::func
var kFunction0 : KFunction0<Unit> = ::func
var kFunction : KFunction<Unit> = ::func
var kCallable : KCallable<Unit> = ::func
var function : Function<Unit> = ::func
```
以上五个对象, 如果两两给对方赋值, 哪些可以编译通过? 如果使用 IDEA 的创建函数功能, IDEA 的默认补全是哪个类型? 如果 func 是一个泛型函数怎么表示?

我们知道 interface 作用是用来弱化 class 的 type 语义 上. 而在 JDK15 (大概)前, kotlin 的密封只能作用于 class 不能作用于 interface, 这是反设计的, 而随着 JDK15 的推出, kotlin 的接口也能被密封了, 而且 JDK15 以前的运行时也支持这个特性, kotlin 的基本盘安卓很长一段时间都不会升级到 15. 当初理由现在看起来不成立了. 很多时候会惊喜地发现 kotlin 居然有这个特性, 然后失望地发现这个特性存在各种各样的陷阱, 这个特性受限于 JVM 就这样, jetbrains 已经做得(当时认为的)最好了.

还有一些我不喜欢的设计, 比如说我可以写出这样的迷惑代码 `fun Unit(Unit : () -> Unit) = Unit(); Unit`, 我们在读代码的时候, 大脑也是容易出 bug 的编译器, 没有必要为了这样的特性丰富 AST.

解构函数也是硬编码, 而且是从 1 开始. 至于协程 null 在调 java 代码时非常难受别人应该都讲过了.

multipart 文件在转成 MultipartFile 的时候必须读完整个流, 所以会缓存到内存或硬盘里, 估计还有别的配置到上限了.

spring.servlet.multipart.max-file-size: -1
spring.servlet.multipart.max-request-size: -1
亲测 ok, 依赖只有 spring-boot-starter-web:3.0.0

@guyeu e.getMessage 改成啥都可以, 重点是要把 error 当第二个参数传进去

@guyeu null 就 null 呗, 异常栈都打出来了

对了打印日志的正确姿势是 log.error(e.getMessage(), e);这样才会打印异常栈

从你发的代码看不出啥问题.
首先得把问题定位到行, 你发的错误中只有信息而没有异常栈, 因为你的 controller catch 到异常没有打印日志(注意要打印异常栈). 打印异常栈后, 再判断是不是在你的 service 中报的错.

如果是在 service 中, 那直接把 service 改成

```
private static void writeFileToLocal(String toLocalFilePath, MultipartFile file) throws IOException {
try(InputStream inputStream = file.getInputStream()){
Files.copy(inputStream, Path.of(toLocalFilePath), StandardCopyOption.REPLACE_EXISTING);
}
}
```
不要直接使用 inputstream, 不要吞异常, 不要 gc;

2019 快回来了吧(指 GDP)

把 read 改成 readAllBytes

国足垃圾是因为国服领先一个版本, 足球不时髦不好看不好玩, 对年轻人毫无吸引力, 等外国也发现看足球不如打 5 把 csgo 的时候国足就崛起了.