@Autowired与Kotlin在@Service中始终为null - 程序园

这语言安排得还真是漂亮…… 我还以为 Kotlin 这个『右值』能是 null 呢，或者 Kotlin 和 @Autowired 一门语言一个 annotation class 在 @Service 这个 annotation class 里皆为空，Java 与您。
不是有 kotlin 的 all-open compiler plugin 吗

apply plugin: 'application'
apply plugin: 'kotlin-spring'
apply plugin: 'kotlin-jpa'
apply plugin: 'org.springframework.boot'
apply plugin: 'io.spring.dependency-management'

classpath "org.jetbrains.kotlin:kotlin-${it}:${kotlinVersion}".toString()
  for it in ['gradle-plugin', 'allopen', 'noarg']
    where kotlinVersion = '1.3.+'

难道不应该吗，它还不需要你 try (db.transactional()) {...}...
比如哪一天有一个用户清奇遭到了 Exception safety 问题，本来是你扣他的工资、给他虚拟物品

在操作皆无原子性（一定会一起失败，不存在中间情况）的时候 （p0: 扣钱; p1: 发货）
+ 要么是你白扣他的钱，然后什么也没说（强盗！），这是 p1 => p0; 反过来就不行
+ 要么是你亏大了（白送），这是 p1 =/> p0，发货肯定扣钱，但是可能被投诉的情况

而有原子性的话处理方便很多，在单机面向用户的时候这肯定很方便啊，不过我觉得可以直接写成函数包起来复用最好，然后就可以用 annotation+kapt 什么的，就不会一定要 transactional {...} 包裹了

try (...: Closeable) { taskRepo.deleteTask(id) } 怎么样呢，虽然不是表达式…… 噢不对 Kotlin 里 try... 是表达式
byCaptureTaskId 的 capture 是什么意思... SQL 语句的 parameter bind?

日卡卡好像写过 sh 脚本来允许利用 app_process 和 android.os.Looper.prepareMainLooper 的 Java service 以 root 执行，不需要很多指令，就是先 kill by name 杀旧服务，然后 su exec 替换掉 shell 就可以了，具体代码可在 GitHub 找 Shizuku manager，貌似有（应该是 Yuuta 个人博客文章看到的）

有的时候不是它不想帮你封装啊……
首先，事务管理本身就是业务逻辑的一部分，虽然不明显，就好象你觉得 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...} 什么的真是太高效了』