有的时候不是它不想帮你封装啊……
首先，事务管理本身就是业务逻辑的一部分，虽然不明显，就好象你觉得 File 要不要 close() 对程序工作无关（更贴切的就是 Timer 得保存引用的问题），可是它就的确有点关系一样（比如，很多时候一个存在锁的 file 不能被同时『打开』很多次，所以不 close 会爆炸）
操作系统是没办法把这个生命周期细化的，JVM 的内存管理也只能管个大概，所以必要的时候程序员就得负责定义这些看起来没用的东西

如果不喜欢的话，那也没办法啊，你可以想象有这么一个库能够把使用自己某个 Transitional CRUD 接口的所有函数都按函数封成事务，可事实是现在很多人连 Java 的 Annotation Processor 都不会写（甚至包括我）
（当然，我相信连 abstract syntax tree 之类的简单递归数据结构都不会处理的人不止我一个）
做不到啊，要不就不写 transaction 算了 😂

也比 Java 之前没 lambda 的时候写什么 new Transaction(db) { @Override void perform...} 强很多啊…… 至少你还能用 Kotlin 的块 db.transaction {...}, 多态起来也更方便了，Java 里要想 db::transaction 返回一个值 R 你还得用局部变量什么的，而且 Java 里面还不行，因为它要求 effective final... 只能弄得像 Android 现在一样，那个封装…… 返回值都不能自动推导

interface ServiceProducer { fun produce(): Service }

interface XXXProducer<out T> { fun produce(): T }

Kotlin 看起来简单，Java 把 Service, T 什么的写很多遍、起一大堆 trivial（泛泛） 的名字。还是多范式编程好，详略适中。

Kotlin 这个真是醉人，.kt:45 ？？？

严重同意
有时候我 IDEA 提示 could be [private]... 我就会忍不住想把本来打算 public 的接口加个 private……

当然我很少写不能够静态类型安全的代码，不过偶尔写到时也会负责地检查我到底为什么要 unchecked，然后负责地 supress 掉 warning

最开始我编程的时候很讨厌 IDEA 的 could be weaker visiblity 提示，后来才慢慢发现其实 IDEA 也蛮对的…… 现在我写的 public 是适度情况了，入门的时候我有这些想法：

+ 『private 不让我调用这个方法/静态方法，所以它很坏，我不能随便使用我弄出来的方法了，为了保证可组合性必须全部 public』
+ 『protected 是什么？ finally 和 catch 有什么区别？』
+ 『必须添加 @Override，不然就不正确』
+ 『某 IDE 能够自动生成 new Button.OnClickListener() {@Override...} 什么的真是太高效了』

唉，不过 Kotlin 的这个 fun/val extension 还真是好，自愧不知，C# 的都没有、Groovy 做得和脚本语言一样意义不太大。不知道没有 extension 的 Kotlin 还能不能算是 Kotlin，现在写个函数都炒鸡方便、标准库也越来越能逼死同人了，其他语言是望尘莫及实锤的…… 😂
完美地打压嘲讽了所有以代码行数论英雄的模板程序员，原来你写了半天自我感觉超好的代码，居然其实是低级重复……