他用 Kotlin 欢快地写成了这样：

interface Effect {
    fun apply(input: Bitmap) : Bitmap
}

并以之为基础接口，至少实现了三个特效。

我在 review 的时候哭笑不得，因为仍然把我提醒过的选项参数给丢掉了，今天我想修复一下。最简单的办法我是知道的，直接向上述 apply 方法中增加一个参数，然后再把那三个实现相应调整过来，再把相关调用也调整过来即可。

但这不符合我作为一个“勤奋的懒人”的直觉。我的第一目标通常是，尽可能少地修改供给侧，尽量不修改消费侧。是否可以新增一个接口方法，原型上加入选项参数，然后将当前这一接口方法改为对新方法的将选型参数置为空的调用呢？经过摸索，以下代码出炉：

interface Effect {
    class Options {
        companion object {
            val default: Options = Options()
        }
    }

    fun apply(input: Bitmap) : Bitmap {
        return apply(input, Options.default)
    }

    fun apply(input: Bitmap, options: Options) : Bitmap
}

然后再去各个具体实现类中把函数签名中加入 options: Effect.Options 这一新的参数即可。点击编译，顺利通过。作为一个 Kotlin 菜鸟，真是要乐出花来。

然而收获胡萝卜结束不久，大棒随之而来。由于我是“一个 Kotlin 菜鸟”，所以在我想新写一个具体特效时，我决定还是使用 Java（主要原因是现成代码会多一些）。我开开心心地写下如下代码后，惊讶地发现，IDE 提示该类对于派生而来的接口的实现不够完整：

public class ShadowEffect implements Effect {
    public Bitmap apply(Bitmap input, Effect.Options options) {
        return null;
    }
}

Java 需要同时实现两个接口函数，成为这样：

public class ShadowEffect implements Effect {
    public Bitmap apply(Bitmap input) {
        return apply(input, null);
    }

    public Bitmap apply(Bitmap input, Effect.Options options) {
        return null;
    }
}

很显然，在 Kotlin 中，interface 同时接纳了 Java 的 abstract 类的部分特性，允许带有具有实现代码的接口函数存在；而 Java 对派生而来的 Kotlin 接口，只接纳其接口函数声明部分，对其具有的实现予以了摒弃。也就是说，将来的其它实现了 Effect 接口的 Java 类，也都要提供自己版本的 Bitmap apply(Bitmap input) 实现，不能从 Kotlin 的现成 fun apply(input: Bitmap) : Bitmap 实现中受益。

如果为了这样一个共同实现的函数的复用，一个可选的（但是笨拙的）方法是，提供一个新的 Java 基类，如下：

public abstract class JavaEffect implements Effect {
    public Bitmap apply(Bitmap input) {
        return apply(input, null);
    }
}

然后将具体实现类的基类调整为它，并把 implements 转换为 extends。当然，在某种程度上这是令人沮丧的，毕竟抽象类跟接口不是一回事。

看起来是时区相关的问题导致的，但是很好奇同在一台设备上，一个系统里，怎么会出现时区问题。留待后续再探。

机器上之前调试过一个开源的 Java 网盘应用，安装了 JDK 8。但是这次写的程序一跑，就会报最低需要 Java 11 的 JDK。

下载了 JDK 11，解压，往 vscode 的 settings.json 中增加了以下设置：

"java.configuration.runtimes": [
        {
            "name": "JavaSE-11",
            "path": "C:\\Dandy\\DevTools\\jdk-11.0.8",
            "default": true
        }
    ],

企图达到报错时的提示文字中提到的 JDK 11 只是 vscode 中 Java debugger 插件的要求，运行时仍可使用老的 Java 版本环境的效果，但怎么也做不到这种两全其美的平衡。最后还是把 JAVA_HOME 环境变量一并改掉才可以。

事后在 https://github.com/redhat-developer/vscode-java/wiki/JDK-Requirements#java.configuration.runtimes 处也能找到如下字样：

Simply defining JavaSE-11 in java.configuration.runtimes is not enough for vscode-java to start, java.home (or any of its alternative environment variables) still needs to point to a valid JDK 11 location.

看上去似乎又是说，不用动系统层面的 JAVA_HOME，而是直接指定 vscode 的 java.home 也可以。没有测试。

项目组织是一个 pom.xml 的文件，一是对 Java 世界的东西不太熟悉，二是对各种开发环境/构建系统也了解不全，已经不清楚 pom.xml 是谁的工程文件了（查了一下，貌似是 Maven 的）。好在 Visual Studio Code 现在够用，能导入。

项目依赖的下载，嗯，在公司的小破网上跑了将近一整天。在此期间，不编译，死写代码。后来到了一个需要阶段性验证的地步，只好先提交到仓库，让其他同学 pull 后编译执行。第一阶段实现一个接口，很顺利，老夫写的代码仅改了一处需要 import 和一个构造函数前少了 public 的问题。

在 Lombok 的加持下（vscode 里也有插件的），跟数据库的交互也很顺畅，简直以为前方就是一马平川了。结果还是 too young too simple 了，而且 this time 就“拿衣物”了。在某个接口的代码完毕之后，程序出现了执行起来很快就退出的情况。没有任何可供探查的信息输出。就是干巴巴的一个通知：

HikariPool-1 – Shutdown initiated…
HikariPool-1 – Shutdown completed.
Stopping service [Tomcat]

怀疑机器内存不够、本机 Java 环境或者其他支撑环境受损、网络不通畅、数据库表处理失当，等等等，无果。最后，老老实实、仔仔细细、逐行代码进行排查，最终发现一个 dao 接口类的方法是元凶。具体到细节，则是 find 动词检索的字段名，其实在该表中是不存在的。在网上能够搜索到的一个事例（https://blog.csdn.net/a704397849/article/details/90648899）表明，注解（或者我进一步理解为代码生成技术）在编程中带来便利的同时，也把隐患埋藏得更深。

整体排查的时间开销，大概是 6 人时。直接导致老夫于凌晨在东直门大街上瑟瑟发抖地等待出租车的到来，上车后哆嗦了至少五分钟，连话都说不完整，也算是一个奇妙的体验。