原java spring boot工程接入kotlin的一些考虑

从网上找了很多kotlin spring boot的文章，一般讲一个简单的请求就完事了。但是距离真正的用到实际业务中还是有一段不小的距离。
kotlin有强制的空与非空的，使得在编写代码前不得不仔细思考这个参数，这个字段的可空性。
kotlin的标准库，在jdk的基础上扩充了不少好用的方法，了解这些方法的使用场景，可以极大的方便代码的编写
kotlin的扩展方法，简直就是各种util的杀手，稍加克制，可与让工程的代码可读性更好

lombok

spring boot接入kotlin的第一个拦路虎就是lombok，lombok非常棒，我在写java的时候非常喜欢，它的不少扩展java的地方，都是直指java的痛点
除开lombok一些特别黑的魔法外，像

@Setter
@Getter
@NoArgContructor
@AllArgContructor

都是比较好消除的，IDEA有

但是，唯独@Slf4j这kotlin比较难办，写业务，不可能不打日志的

JSR 303 - Bean Validation

jsr 303无疑也是非常棒的，只是到了kotlin这里有点水土不服，要改不少东西。
使用这个标准给web开发带来极大的便利，但是与kotlin冲突非常大

• 无法实例化data class
  比如

data class Param(
val name: String
)
// 省略其他
    @GetMapping("/param")
    fun testGetParam(
            @Validated param: Param
    ) : Response {
        println(param)
        return success(param)
    }

如果参数传了name，没问题，可以实例化
如果没有传name，就直接500了，没有走jsr 303的流程
这就导致与现有的工程结合比较麻烦
如果定默认值为空，那就失去了使用kotlin的本意了
还不如lombok

@Value
public class Param {
    @NotBlank(message = "name不能为空")
    private String name;
}

先挖坑，后面填

MyBatis

默认的final 与 AOP冲突

不得不用到AllOpen的编译器插件